Mailman 3 August 2004 - Python-Dev

2.3.4 on Win64?
by Nick Bastin Aug. 11, 2004

Aug. 11, 2004

Has anybody built 2.3.4 on Win64, and if so, is there a preferred way? We built it by exporting the makefiles and twiddling with the linker options and pointer size in pyconfig.h, but that seems a bit kludgy. -- Nick

2 3

deco_fun_expr(= vs. @deco_fun_expr
by bokr＠oz.net Aug. 11, 2004

Aug. 11, 2004

Just wanted to make sure this got into python-dev as an alternative ;-) Example using post-fixed '(=' instead of prefixed '@': deco1(= decomodule.deco2(= def foo(): pass effect is same as with prefixed-@ syntax, i.e., foo = deco1(decomodule.deco2(foo)) (except either way there's no intermediate foo binding during evaluation, I gather?) Advantages: 1. currently illegal syntax, UIAM 2. lets callable-returning expression have unchanged grammar up to new (= trailer part 2. doesn't use up '@' or interfere with tools that use it 3. expresses calling in the proper nested way (inner before outer). No confusion about "backwards." 4. Leaves the door open to callable-calls operating on other code-block-derived arguments than from def and its suite (e.g. class and suite). Leaves door open for explicit =) end-of-block-arg mark if that should turn out useful for demarcation of otherwise ambiguous block endings, for some future use. Unfortunately vexing personal matters will demand priority attention for some time again :-( Bye for now. Regards, Bengt Richter

1 0

RE: [Python-Dev] Re: Decimal type question [Prothon]
by Michael Chermside Aug. 11, 2004

Aug. 11, 2004

Mark Hahn writes: > I am more interested now in hearing about people's feelings > on the idea of > having the Decimal type "in-between" Int and Float. Assume a decent > Decimal implementation is used. All right. I think that "in-between" Int and Float is a bad idea -- or at least that it's a bad way to think about a decent design. "in-between" suggests that Float has greater range than Decimal which has greater range than Int... but in your design that simply isn't true. Your Int, for instance, can represent values that neither Decimal nor Float can handle. So the "right" way (IMHO) to think about it is as three *different* classes of numbers. There are Ints (can only handle integers, but able to manage any of those), Decimals (can only handle certain rational numbers but it happens to be those that humans often find useful; also has an upper bound and a precision limit (which may vary with size depending on what implementation you use)), and Floats (can only handle certain rational numbers most of which are NOT the same as those handled by Decimal; also has upper bounds and precision limits; runs real fast). I would recomend that you AVOID "automatic" conversion (just like Python does) but that you make sure that when a (pure) number can be represented in two ways that they compare equal. So the following would be true: Int(1) == Decimal(1.0) == Float(1.e0) Decimal(2.5) == Float(2.5e0) This is pretty much what you are already doing... for instance, Int(1) / Int(3) ---> Decimal(0.3333333333333333) because there is a "/" operator which accepts two Ints or Decimals and returns a Decimal. I'd propose that there's also another "/" operator which accepts two Floats and returns a Float. And that passing one Float and one (Int or Decimal) to "/" results in a type error. The cos() function would accept one number (of any type) and return a Float. There's also the question (and it's an important one!) of what literals to use. I agree (and everyone else would too) that literals like "1234" should create Ints. I also agree (as would everyone else) that literals like "123.45e6" should create Floats. The contraversial bit is whether literals like "123.45" should create Decimals... but I think that they should. My reasons are (1) for newbies, matching what people expect is more important than speed... and that's exactly why Decimal is better than Float, and (2) if not, then what form WOULD you use for Decimal literals? (I suppose there's always the trailing "d".)

2 1

Re: [Python-Dev] A decorator syntax not yet mentioned (I think!)
by John Marshall Aug. 11, 2004

Aug. 11, 2004

On Wed, 2004-08-11 at 15:29, Bob Ippolito wrote: > On Aug 11, 2004, at 11:16 AM, John Marshall wrote: > > > How about the following, which I am almost positive > > has not been suggested: > > ----- > > class Klass: > > def __init__(self, name): > > self.name = name > > > > deco meth0: > > staticmethod > > def meth0(x): > > return x > > > > deco meth1: > > classmethod > > def meth1(cls): > > return cls > > > > deco sayhello: > > funcattrs(name='GvR', language='python') > > log(file='func.log') > > def sayhello(self): > > print 'hello python world' > > > > ----- > > 1) The decorators clearly apply to a specific method/function, > > therefore there is no need to do any stack pushing in memory > > until the method/function definition is done. > > None of that code can actually execute until the method/function > definition is done, how is this different at all? > I am not refering to actually executing the code but addressing people's point that when they read through the code, they need to keep all the decorator items in memory until they come to the "def ...". One person described the process as push each decorator onto a stack (in his head) until he found the def. > > 2) The decorators are "outside" of the method/function they > > decorate: > > a) which will please those who want the outside location > > b) will not be folded within the function > > Doesn't a) imply b)? > Sure. But this addresses two concerns explicitly. > > c) folding on the decorators can be done so that the > > def is not obfuscated > > This could probably be done with the @syntax too if the editor was > smart enough I imagine it is possible. But the point was to make the signature clearly visible/prominent but also indicate that there _are_ decorators associated with the method/function. > > > d) can be located anywhere in the code--but most likely > > before the "def ...()" > > I don't think that is a bonus at all. > I am not claiming this as a bonus. Rather, I am making it clear that the mention of the method/function name does not require any special/forced placement. > > 3) The sequence in which the decorators are applied is just > > like code would be--this is certainly intuitive given > > that we are writing code. > > That's not really obvious. > I am not claiming that it is obvious but that it could be understood that way (rather than leave it to interpretation, I made it explicit as an option). Note how the sequence issue has come up recently with respect to the @-syntax and the list syntax, which apparently have been understood to apply in the opposite order. > > This approach could also be applied to classes in case > > decorators should ever be extended to them: > > So can any of the other proposals. That may be, but to be able to do so this way makes it an viable option. > > > ----- > > deco Klass: > > doc("This is a class to ...") > > class Klass: > > : > > : > > ----- > > > > Any comments? > > Yeah, this is no less than twice as bad as any of the current decorator > proposals because you have to repeat the function name :) > Personally, I might opt for something else, but having the decorators outside have raised concerns for some. With this approach the tagging makes things explicit, which is often a good thing. The current @-syntax _implicitly_ identifies the decorators with the method/function/class which people have said they don't like. Thanks for the comments. John > -bob

1 0

A decorator syntax not yet mentioned (I think!)
by John Marshall Aug. 11, 2004

Aug. 11, 2004

How about the following, which I am almost positive has not been suggested: ----- class Klass: def __init__(self, name): self.name = name deco meth0: staticmethod def meth0(x): return x deco meth1: classmethod def meth1(cls): return cls deco sayhello: funcattrs(name='GvR', language='python') log(file='func.log') def sayhello(self): print 'hello python world' ----- 1) The decorators clearly apply to a specific method/function, therefore there is no need to do any stack pushing in memory until the method/function definition is done. 2) The decorators are "outside" of the method/function they decorate: a) which will please those who want the outside location b) will not be folded within the function c) folding on the decorators can be done so that the def is not obfuscated d) can be located anywhere in the code--but most likely before the "def ...()" 3) The sequence in which the decorators are applied is just like code would be--this is certainly intuitive given that we are writing code. This approach could also be applied to classes in case decorators should ever be extended to them: ----- deco Klass: doc("This is a class to ...") class Klass: : : ----- Any comments? John

2 1

Long term plans for Python?
by Edward C. Jones Aug. 11, 2004

Aug. 11, 2004

What are the long term plans for changes in Python from 2.5 to 3.0 and beyond?

1 0

Request for bug closures
by Nick Coghlan Aug. 11, 2004

Aug. 11, 2004

There are a couple of bugs which can probably be closed: #1006001 (Future warning in test_format.py): Looks like a problem with the user accidentally running the 2.4 regrtest.py with the 2.3 interpreter #1006740 ('Memory leak' in long running console window): Looks like the user has encountered a Windows 'feature', not a Python bug. Cheers, Nick. -- Nick Coghlan | Eugene, Oregon Email: ncoghlan(a)email.com | USA

2 1

IPython, @, and option E from the wiki
by Fernando Perez Aug. 11, 2004

Aug. 11, 2004

Hi all, since the developers have been kind enough to take ipython's fate into account in the decorator debate, I figured I'd post an additional piece of info. Option E on the Wiki http://www.python.org/moin/PythonDecorators is: E. pie decorator at top of function body syntax def foo(arg1,arg2): @classmethod ... def bar(low,high): @accepts(int,int) @returns(float) ... I just want to mention a couple of things regarding this one, in case it becomes a contender in Guido's mind: 1. It would NOT cause ipython any problems whatsoever. Ipython only special-cases @foo at the beginning of a line, so this would be perfectly OK with ipython. I don't know if Leo would fare equally well with it. 2. I happen to like it quite a bit, since I already consider (because of the special role of docstrings) the top area of a function 'special'. So that area seems to me a reasonable choice for additional meta-information about the function's behavior. I agree decorators are more radical than docstrings, but at least there's a certain conceptual precedent. And it seems to leave the cleanness of the 'def' word which is a nice visible highlight of a function declaration, without causing the deep indentation issues of other proposals. 3. In this kind of setup, using | instead of @ would be ok as well, I guess: def bar(low,high): |accepts(int,int) |returns(float) ... Ok, nobody really wanted my opinion, so feel free to ignore #2/3 :) The main point was #1. Best, f

2 2

Unifying Long Integers and Integers: baseint
by Dmitry Vasiliev Aug. 11, 2004

Aug. 11, 2004

Is there a plan for implementing a base class for int and long (like basestring for str and unicode): >>> issubclass(int, baseint) and issubclass(long, baseint) True ? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru

7 12

2.4a2, and @decorators
by Anthony Baxter Aug. 11, 2004

Aug. 11, 2004

The @decorator patch has been landed on the trunk, after getting the go-ahead from the BDFL. I'll update PEP-0318 with the final syntax in the next day or so. We're aiming for 2.4a2 this Thursday - so can people please hold off on checking into the trunk from Wednesday evening onwards, please. At the moment, I'm guessing we're going to have a 2.4a3 in a couple of weeks. Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

32 112