Mailman 3 February 2003 - Python-Dev

non-binary operators
by Gerald S. Williams Feb. 14, 2003

Feb. 14, 2003

I'm *not* discussing PEP 308, since that's supposed to be happening on c.l.py. The operator names have been changed to protect the innocent. :-) Gary Herron wrote: > The above defines two binary operators "[POINTED]" and > "[STICK]" and a ternary operator "[POINTED]...[STICK]". [...] > can the action of the ternary operator be defined in > terms of the actions of the two binary operators? [...] > The answer is *NO*, all three expressions evaluate to > different results. Why is that any different from the following set, which are already three different expressions in Python? ( bunch_of_grapes < banana ) < pointed_stick bunch_of_grapes < ( banana < pointed_stick ) bunch_of_grapes < banana < pointed_stick -Jerry

2 1

PEP308 alternative syntax: bool method
by Mark Russell Feb. 14, 2003

Feb. 14, 2003

I know this subject has been beaten somewhat to death, but how about making the if/then/else operator a method of the bool type, as in: var = (x > 10).choose(ifyes, ifno) Choose() would need to be a special function of course to avoid evaluating the non-selected choice. I haven't seen this syntax proposed before, although I have not waded through all the debate in comp.lang.python. I would love to see some form of choice operator added, mainly because it supports a functional style of programming -- I very much like to initialise variables as they are introduced (and preferably not to assign to them later). Mark Russell

3 2

import curdir,pardir,sep,pathsep,defpath from relevant *path module
by Skip Montanaro Feb. 14, 2003

Feb. 14, 2003

It has always mystified me that os.{sep,pathsep} aren't defined in os.path. Looking at os.py I see that os.{curdir,pardir,defpath} should probably live there as well. Proposal: Move the definitions of curdir, pardir, sep, pathsep and defpath into the relevant path module (ntpath, posixpath, etc), then for compatibility reimport them ("from path import curdir, pardir, sep, pathsep, defpath") later in os.py. Update the libref documentation to reflect these items' new home. Do whatever is necessary deprecation-wise (silent in 2.3? Update usage in Python source after 2.3 release and add visible deprecation in 2.4?). Rationale: These variables are all path-related. One of the reasons for having platform-specific path modules is to allow programmers to manipulate filesystem paths for platform X on platform Y. This would make those items available under that sort of scenario. It would also reduce the amount of platform-specific code in os.py. Skip

4 8

Changing SF tracker email preferences
by Guido van Rossum Feb. 14, 2003

Feb. 14, 2003

When a new bug or patch is posted to a SF tracker, an email gets sent to python-bugs-list(a)python.org or patches(a)python.org. But... when anything is changed or added to those trackers, an email is *also* sent to those lists. I would like to receive the first kind of traffic (new tracker issues) but not the second kind, except for those tracker issues in which I am interested (which I can get by explicit turning on monitoring of those issues, or by following up). The SF tracker admin has an option to allow this: all I have to do is uncheck the box that says "Send email on all changes". I would really like to do this. Would anybody who is currently receiving bugs or patches traffic be bothered if I made this change? --Guido van Rossum (home page: http://www.python.org/~guido/)

6 8

Re: [Python-Dev] Change definition of Py_END_ALLOW_THREADS?
by Gerald S. Williams Feb. 14, 2003

Feb. 14, 2003

Mark Hammond wrote: > My entire problem is solved simply by making the API look like: > > old_state = PyAutoThreadState_Ensure(); > ... > PyAutoThreadState_Release(old_state); Aargh! I had an e-mail composed about that right away, but didn't press send for fear of increasing the noise level of Python-Dev even more. When you said saving of state is a PITA, I figured you meant that this wasn't going to work so easily. (Next time I'll at least send a private e-mail.) Should there be Py_BEGIN_AUTO_THREAD_STATE_ENSURE and Py_END_AUTO_THREAD_STATE_ENSURE macros (analogous to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS) as well, then? -Jerry

5 7

Re: [Python-checkins] python/nondist/peps pep-0311.txt,NONE,1.1
by Just van Rossum Feb. 14, 2003

Feb. 14, 2003

mhammond(a)users.sourceforge.net wrote: > Open Issues > This is where I note comments from people that are yet to be resolved. > - JustvR prefers a PyGIL prefix over PyAutoThreadState. > - JackJ notes that the "Auto" prefix will look a little silly > in a few years, assuming this becomes the standard way of > managing the lock. He doesn't really like Just's "GIL", and > suggested "PyIntLock" Oh, so now we're locking integers? ;-) The reason I don't like "Auto" is that there's nothing automatic going on: you still have to _use_ the API actively... My opinion is biased because very recently I wrote a module called "autoGIL" for OSX, which actually _does_ handle the GIL automatically, in the context of event loops: it releases the GIL when the event loop goes to sleep and acquires it when it wakes up again. This works for us as the even loop is not supposed to use blocking calls to begin with. Handling the GIL the "proper" way in this project (PyObjC) would be impossible without PEP 311, but even with it, it will be an huge amount of work. I like PyGIL for the prefix as "GIL" is a well understood acronym; you can't really discuss the issues without using it... But it's totally your call. Just

1 0

Updated AutoThreadState pre-PEP
by Mark Hammond Feb. 13, 2003

Feb. 13, 2003

Hi all, I have updated my pre-PEP, and am about to start the process of making it a real PEP :) I have attached the latest and greatest version here. I believe it largely complete. There is a fully functional, platform independent implementation at http://www.python.org/sf/684256 All comments, reviews, tests and anything else welcome. Mark.

1 1

PEP-242 Numeric kinds -- disposition
by Paul Dubois Feb. 13, 2003

Feb. 13, 2003

PEP-242 should be closed. The kinds module will not be added to the standard library. There was no opposition to the proposal but only mild interest in using it, not enough to justify adding the module to the standard library. Instead, it will be made available as a separate distribution item at the Numerical Python site. At the next release of Numerical Python, it will no longer be a part of the Numeric distribution.

1 0

RE: [Python-Dev] Updated AutoThreadState pre-PEP
by Mark Hammond Feb. 13, 2003

Feb. 13, 2003

[Aahz, in private mail, provokes an interesting point] > "What happens if you do PyAutoThreadState_Ensure() and > PyEval_InitThreads() has not been called?" > > There should be some discussion of the appropriate time to call > PyEval_InitThreads(). Yeah, this is an interesting, indirect point. If the author must call PyEval_InitThreads(), then they must also have called Py_Initialize(). If in the real world, all users of this API have already done this at process startup, then our internal checks for initialization are pointless. Therefore, I propose that I change the PEP to state that before the AutoThreadState API can be used, Python must have been "correctly initialized", where "correctly initialized" is defined as: * Py_Initialize() has been called. * If the extension is multi-threaded, then PyEval_InitThreads() has been called from the "main thread". If these conditions are not met, Python will either (and hopefully usually) Py_FatalError(), or occasionally dead-lock. Any objections? Mark.

1 0

dict "setdefault". Feaure request or bugfix?
by Jesus Cea Avion Feb. 13, 2003

Feb. 13, 2003

<https://sourceforge.net/tracker/index.php?func=detail&aid=684542&group_id=5…> Reading "python cookbook" I reach a very intelligent dictionary construction: to use dictionary "setdefault" to avoid a "get" or a "try...except". Nevertheless current "setdefault" behaviour is questionable, since it evaluates the default value when it is not necessary. In my mind, "setdefault" should evaluate the default value when it need to use it, not ALWAYS. Example: >>> a={} >>> def b() : ... print "hi!" ... return 1 ... >>> a.setdefault("hola","hello") hello >>> print a {'hola': 'hello'} >>> a.setdefault("hola",b()) hi! 'hello' In the example, the "setdefault" evaluation is not necessary since 'a["hola"]' already exists. But the default function is called, although its return value will be ignored. This behaviour is not intuitive and I think it should be changed or, at least, documented. The change would be very welcome when the "setdefault" default code is expensive, like my application. In any case, the change would be ALWAYS more efficient, even in the tipical "[]" case. Perhaps a "form __future__ import setdefaultNG" would be necessary to help to update legacy code? Opinions?. -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea(a)argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ _/_/_/_/_/ PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

9 13