Re: [Python-Dev] reducing self.x=x; self.y=y; self.z=z boilerplate code
Nick Coghlan wrote:
[...]
> If the right hand side of 'as' permitted the same forms as are going
> to be permitted for the 'as' clause in 'with' statements, then Ralf's
> situation could be handled via:
>
>def __init__(self as s, x as s.x, y as s.y, z as s.z):
> pass
>
> Essentially, it allows arguments to be given two names - a public name
> (before the 'as', used for keyword arguments), and a private name
> (after the 'as', not used for keyword arguments, allows easy shorthand
> aliasing of self, unpacking of tuple arguments, and easy assignment of
> instance variables).
There once was a suggestion like this on c.l.py, expanding this to other
statements, like:
if re.match('a.*b', text) as m:
# do something
What has become of this? It seems to be a wanted feature, and while I concur
that classic 'C-style' assignment-as-expression is undesirable (because of
the =/== bug-source), this would be a way, wouldn't it?
Reinhold
--
Mail address is perfectly valid!
___
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] reducing self.x=x; self.y=y; self.z=z boilerplate code
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote:
> 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?
I had assumed that you were a 'go-getter', and that you would want to
figure it out yourself. Apparently I was wrong.
Being that I don't use metaclasses (I don't need the functionality), I
had to spend 10 minutes learning about them, and 5 minutes implementing
the following.
class AutoSlots(type):
def __init__(cls, name, bases, dct):
slots = dict.fromkeys(dct.get('__slots__', []))
if '__init__' in dct:
init = dct['__init__']
ifvn = init.func_code.co_varnames
for i in xrange(init.func_code.co_argcount):
x = ifvn[i]
if x[:1] == '_'and x[1:] not in slots:
slots[x[1:]] = None
if slots:
dct['__slots__'] = slots.keys()
super(AutoSlots, cls).__init__(name, bases, dct)
def InitSlots(ob, args):
for k, v in args.items():
if k[:1] == '_':
setattr(ob,k[1:],v)
class Foo(object):
__metaclass__ = AutoSlots
def __init__(self, a, b, _x, _y=None):
InitSlots(self, locals())
>>> foo = Foo(1,2,3)
>>> vars(foo)
{'y': None, 'x': 3}
> > 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!
Yes you are. Any thing that changes syntax, necessarily is a syntax
change. People get "agitated" because with every syntax addition, that
is just another syntax that a newbie may need to learn in order to
understand some block of code. Further, for those of us who try to
teach about it, it is just one more little nit that students ask about.
Considering that EVERYTHING you want is possible with 17 lines of
support code (which can be tossed into site and assigned to __builtins__),
and 2 lines of boilerplate (which can be made into one metaclass line if
you are willing to do a bit more work), a syntax change is foolishness.
> I know enhancing the syntax is work, but shouldn't a syntax leading to
> less code clutter be the higher value?
Why bother if the non-syntax-change goes 99% of the way? I've further
pushed myself to -10 for any syntax change offering during my
implementation of AutoSlots.
- Josiah
___
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] reducing self.x=x; self.y=y; self.z=z boilerplate code
"Ralf W. Grosse-Kunstleve" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'd also be happy with > > def __init__(self, self.x, self.y, self.z): > > which wouldn't be too different from unpacking tuples If you are willing to require that the args be passed as a tuple (extra pair of parens) I believe you could do def __init__(s, args): s.x, s.y, s.z = args This even checks for correct number of actual args. I believe part of your underlying point is that you do not (usually) in this type of situation really need or want the args to be separately named locals since you just want to attach them to the instance. (Way too late, may have made an error.) Terry J. Reedy ___ 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] Money module
On 7/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Facundo]
> > The pre-PEP is almost done, and the corresponding
> > test cases are all written.
>
> What is the part about the pre-PEP? Something like this probably
> shouldn't go in the standard library until it has been proven in the
> field. This doubly true for a module that has made some unusual OO
Well, maybe the pre-PEP is not a good name.
My {name:concept} mapping for pre-PEP is something like "document that
has all the reasons, rationale and examples and everything like a good
PEP, but it's not a PEP yet (maybe never won't be)".
Making a pre-PEP, and not filling a bunch of other documents, is a
good way for me to document everything as it should be.
> * The exchange rate mechanism may end-up not being workable as it does
> not incorporate rate changes over time, differing forward and reverse
> rates, non-linear factors such as commission/fees, source currency, or
> multiple suppliers.
Are you talking about the exch_rate attribute of Currency? Our idea
for it is to record the necessary exchange rates, *at creation time*,
between the object's currency type and whatever you'd like to store.
> * Time value of money computations are typically dimensionless (not
> sensitive to currency type or formatting) and they often have algorithm
> specific rounding needs (round at the end of compounding period or each
> year or only at the end).
We think that it'd nice to have TVM functions inside a money module,
so if you want to do some math abouth this you just import the module
and use it.
It's not so much related to Currency data type, it's just that we
think that this module is the right place to put those functions.
Don't think that these generic functions use in some way the Currency
data type of its Context.
> * The absence of a division operator may prove problematic for
> allocation routines.
In what sense? I don't understand what you mean, sorry.
BTW, we take out the "/" operator because it's to tricky to use for
the final user. Being (in the context) dec_places=2 and
trap_inexact=True (both defaults), doing Currency(1)/2 is ok, but
doing Currency(1)/3 will give you an exception.
So, the idea is the user to don't have a division operator, for him to
have to look at distrib() method, and be aware of all the issues
involved.
Another concept we discussed here is that Currency() should do money
operations *only*, as safer as we could. If you want to start doing
some generic arithmetic operations, like calculating the average
between a list of prices, you should convert it to Decimal and use it
as a number and not a currency.
Take note that we're not against using currency as a number *if and
only if* it won't affect your currency behaviour (or safety).
> * Usually numeric formatting is kept independent from the rest of the
> design. It will be interesting to see how workable it is to make it
> part of the Context object. In Excel for instance, formatting is a
We put the formatting configuration in the context, because we thought
is the best way to store your config, change it for one thread, change
it for all threads, use a different formatting from another specific
context, etc... basically, the same liberty that gives you the context
for the other configuration, but for the formatting.
The formatting function itself will be a separate function in the code
(*cough* we'll use your function from Decimal recipe *cough*).
> While the Money module remains experimental, it should remain a
> third-party package.
Indeed! And maybe will still be a third-party package after it
finished being experimental.
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] reducing self.x=x; self.y=y; self.z=z boilerplate code
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 ___ 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] Money module
On Sat, Jul 02, 2005, Facundo Batista wrote: > On 7/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> >> * Time value of money computations are typically dimensionless (not >> sensitive to currency type or formatting) and they often have algorithm >> specific rounding needs (round at the end of compounding period or each >> year or only at the end). > > We think that it'd nice to have TVM functions inside a money module, > so if you want to do some math abouth this you just import the module > and use it. > > It's not so much related to Currency data type, it's just that we > think that this module is the right place to put those functions. > Don't think that these generic functions use in some way the Currency > data type of its Context. Sounds like a better way to go is a Money package (or perhaps a Financial package) and just create the Currency module within it for now. Anyway, given that this isn't going to be a real PEP any time soon, please restrict the discussion to comp.lang.python. Thanks for your help keeping python-dev clutter-free. ;-) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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] Terminology for PEP 343
On Friday 01 July 2005 10:45 am, Fred L. Drake, Jr. wrote: > On Friday 01 July 2005 11:44, Phillip J. Eby wrote: > > Resource managers. > > Yeah, I was thinking that, but was somewhat ambivalent. But I definately > like it better than anything else proposed so far. I like that as well. My hat in the ring would be "brackets" or "bracketed statements", implying there is something before, after and in the middle. Also not an acronym, and short. And while we're on naming issues... Regarding __enter__/__exit__ versus __enter__/__leave__, I like the latter not only because of ASM history but that the two are the same length, making documentation cleaner in some cases. ENTER: blah blah LEAVE: blah blah A minor item, but then I'm big on visual symmetry. ;-) -Jeff ___ 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] Terminology for PEP 343
Raymond Hettinger wrote: > Hmm, that got me to thinking a bit more. Here's another subjective two > cents worth. "exit" seems to be a more global concept and "leave" seems > more local. For instance, I leave a room but exit a building. In > Python, sys.exit and os._exit are grand exits rather than local exits > for functions or modules. Yes, but it's not simply an enter, or an exit. The most accurate association I can think of is "initiate" and "finalize". They indicate a process is being done on the way in and out, where as "enter", "leave" and "exit" do not. But the context might vary depending on what is actually being done so it has to remain fairly general. The words "enter" and "exit" are nice because they are fairly straight forward, familiar, and short to type. But they don't really imply any association to the with blocks. So they may be on the side of being too general. An alternative that has been associated to blocks in other languages is "begin" and "end". So it could be a "Resource Manager Block", which uses a "__begin__" and "__end__" method, which is defined in a "Resource Manger" object or a "Resource Manager Generator" object, which is called by the 'with' key word. Maybe someone can rephrase that a bit better. :) Cheers, Ron ___ 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
