Re: Access to the caller's globals, not your own

2016-11-17 Thread Rob Gaddi
Steven D'Aprano wrote: > On Thursday 17 November 2016 04:52, Rob Gaddi wrote: > >>> import library >>> result = library.make_spam(arg) >>> >>> >>> versus: >>> >>> import library >>> make_spam = library.make_library() >>> result = make_spam(arg) >>> >>> What a drag. >>> >>> >> >> And there you hav

Re: Access to the caller's globals, not your own

2016-11-17 Thread MRAB
On 2016-11-17 05:40, Dan Sommers wrote: On Thu, 17 Nov 2016 16:17:51 +1100, Steven D'Aprano wrote: ... factory functions are great. But I'm saying that as the writer of the library, not the user of the library. Can you imagine expecting users to do this? from math import trig sin = trig.buil

Re: Access to the caller's globals, not your own

2016-11-16 Thread Dan Sommers
On Thu, 17 Nov 2016 16:17:51 +1100, Steven D'Aprano wrote: > ... factory functions are great. But I'm saying that as the writer of > the library, not the user of the library. Can you imagine expecting > users to do this? > from math import trig > sin = trig.build('sine') > result = sin(0.1) No,

Re: Access to the caller's globals, not your own

2016-11-16 Thread Steven D'Aprano
On Thursday 17 November 2016 04:52, Rob Gaddi wrote: >> import library >> result = library.make_spam(arg) >> >> >> versus: >> >> import library >> make_spam = library.make_library() >> result = make_spam(arg) >> >> What a drag. >> >> > > And there you have it; an entire extra line at import time.

Re: Access to the caller's globals, not your own

2016-11-16 Thread Rob Gaddi
Steven D'Aprano wrote: > On Tuesday 15 November 2016 15:55, Dan Sommers wrote: > >> On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote: >> >>> import library >>> SPAMIFY = False # only affects this module, no other modules >>> result = library.make_spam(99) >> >> I must be missing someth

Re: Access to the caller's globals, not your own

2016-11-16 Thread Antoon Pardon
Op 16-11-16 om 09:36 schreef Steven D'Aprano: > On Tuesday 15 November 2016 15:55, Dan Sommers wrote: > >> On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote: >> >>> import library >>> SPAMIFY = False # only affects this module, no other modules >>> result = library.make_spam(99) >> I must

Re: Access to the caller's globals, not your own

2016-11-16 Thread Ethan Furman
On 11/16/2016 12:36 AM, Steven D'Aprano wrote: But, for what its worth... I have a function, let's call it quartile(data, n). Unfortunately there's about a dozen different ways to calculate quartiles, and they all give ever-so- slightly different results. So I end up with: def quartile(data, n

Re: Access to the caller's globals, not your own

2016-11-16 Thread Steven D'Aprano
On Tuesday 15 November 2016 15:55, Dan Sommers wrote: > On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote: > >> import library >> SPAMIFY = False # only affects this module, no other modules >> result = library.make_spam(99) > > I must be missing something, because it seems too obvious:

Re: Access to the caller's globals, not your own

2016-11-16 Thread Steven D'Aprano
On Tuesday 15 November 2016 07:04, ojacob...@heroku.com wrote: > On Monday, November 14, 2016 at 12:21:00 AM UTC-5, Steven D'Aprano wrote: > >> Don't tell me to make SPAMIFY a parameter of the function. I know that. >> That's what I would normally do, but *occasionally* it is still useful to >> h

Re: Access to the caller's globals, not your own

2016-11-16 Thread Steven D'Aprano
On Monday 14 November 2016 16:55, eryk sun wrote: > On Mon, Nov 14, 2016 at 5:20 AM, Steven D'Aprano > wrote: >> but what magic do I need? globals() is no good, because it returns the >> library's global namespace, not the caller's. >> >> Any solution ought to work for CPython, IronPython and Jyt

Re: Access to the caller's globals, not your own

2016-11-14 Thread Dan Sommers
On Mon, 14 Nov 2016 16:20:49 +1100, Steven D'Aprano wrote: > import library > SPAMIFY = False # only affects this module, no other modules > result = library.make_spam(99) I must be missing something, because it seems too obvious: import library # only affects this module, no other modu

Re: Access to the caller's globals, not your own

2016-11-14 Thread ojacobson
On Monday, November 14, 2016 at 12:21:00 AM UTC-5, Steven D'Aprano wrote: > Don't tell me to make SPAMIFY a parameter of the function. I know that. > That's > what I would normally do, but *occasionally* it is still useful to have a > global configuration setting, and those are the cases I'm ta

Re: Access to the caller's globals, not your own

2016-11-14 Thread Rob Gaddi
Steven D'Aprano wrote: > Suppose I have a library function that reads a global configuration setting: > > # Toy example > SPAMIFY = True > def make_spam(n): > if SPAMIFY: > return "spam"*n > else: > return "ham"*n > > > Don't tell me to make SPAMIFY a parameter of the funct

Re: Access to the caller's globals, not your own

2016-11-13 Thread eryk sun
On Mon, Nov 14, 2016 at 5:20 AM, Steven D'Aprano wrote: > but what magic do I need? globals() is no good, because it returns the > library's global namespace, not the caller's. > > Any solution ought to work for CPython, IronPython and Jython, at a minimum. You can access the globals of the calle

Access to the caller's globals, not your own

2016-11-13 Thread Steven D'Aprano
Suppose I have a library function that reads a global configuration setting: # Toy example SPAMIFY = True def make_spam(n): if SPAMIFY: return "spam"*n else: return "ham"*n Don't tell me to make SPAMIFY a parameter of the function. I know that. That's what I would normal