Re: Lisp-likeness

"Carl Banks" <[EMAIL PROTECTED]> writes: > Michele Simionato wrote: > > Carl Banks: > > > If Python did it the way Scheme did, this would be pretty useless. > > > > But notice that Scheme has no problems whatsoever: > > > > (define (toplevel) > > (define a 1) > > (define (f) > > (display a

Re: Logging global assignments

Larry Bates <[EMAIL PROTECTED]> writes: > Suggestion: > Use ConfigParser to set your globals instead and you can track > your assignments over each file, section and option in the file. I would dearly love to go down this sort of route but, unfortunately, they are not _my_ configuration files, an

Logging global assignments

I am dealing with an application which reads in configurations by calling (a wrapper around) execfile. Any configuration file may itself execfile other configuration files in the same manner. I would like to create a log containing all global assignments made in these files. Comparing the globals

Re: Python 2.4 removes None data type?

Warren Postma <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > I just read in the 'What's New in Python 2.4' document that the None > > data type was converted to a constant: > > http://python.org/doc/2.4/whatsnew/node15.html > > Implication: A long standing wart in Python now gone.

Re: type of simple object

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Hello Jacek, > > Thanks for the answer, > > Can you tell me how can I check if an object is a sequence (you are > right, this is actually what I want)? You try to use it as a sequence. If it works, then it was a sequence. If it was not a sequenc

Re: type of simple object

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > Thank you guys. > > My function should multiply every element of a list, for example > "something" > and "something" can be an integer or another list. > If it deals with integer than it is ok, but > If it deals with list than it become false for

Re: type of simple object

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > The result > How can I check it since it is not a string right? It is a type, which is a first-class object in its own right. type('hello') == str However, I reiterate, you almost certainly don't really care about what the actual type is. T

Re: Python's idiom for function overloads

Philippe Fremy <[EMAIL PROTECTED]> writes: > Enforcing types also brings the benefit that the program is more > deterministic. In my experience, there is a lot more benefits to have > an object whose type is clearly identified than to have function that > accepts generic objects. > > > I would g

Re: type of simple object

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > How do I know type of simple object is tuple or list or integer, for > example my function should understand what is the object type passed in > its argument Answers ordered in decreasing degree of Pythonicity: 1) You are mistaken, the function

Re: Next step after pychecker

Paul Rubin writes: > Philippe Fremy <[EMAIL PROTECTED]> writes: > > I would like to develop a tool that goes one step further than > > pychecker to ensure python program validity. The idea would be to get > > close to what people get on ocaml: a static verification of al

Re: Python's idiom for function overloads

"F. GEIGER" <[EMAIL PROTECTED]> writes: > As Philippe already said, use objects that support the protocol or decide > what to do with it after having checked its type. I do that, if I have to, > like so: > > 1 def doIt(arg): > 2if type(arg) == type([]): > 3map(doIt, arg) > 4 else

Re: Python's idiom for function overloads

Philippe Fremy <[EMAIL PROTECTED]> writes: > Hi Frans, > > > Since Python doesn't have static typing, how is the same result as > > traditional function overloads results in acheived? > > > With dynamic typing obviously. :-) > > You can not reproduce the C++ overload idiom Of course you

Re: variable declaration

"Michael Tobis" <[EMAIL PROTECTED]> writes: > In fact, I'd recommend a paragraph early in the Nutshell book saying > "there are no declarations, no use strict, no implicit none, sorry, > forget it", It would have to be a pretty long paragraph, if it were to list all the things that you do NOT fin

Re: from __future__ import decorators

Tim Roberts <[EMAIL PROTECTED]> writes: > Jacek Generowicz <[EMAIL PROTECTED]> wrote: > > > >I have some code, which makes copious use of the @decorator syntax > > I'm very curious to know what kind of application you are writing in which > "copious

Re: from __future__ import decorators

Skip Montanaro <[EMAIL PROTECTED]> writes: > Jacek> Crazy idea ... would it be possible to shadow 2.3's parser with > Jacek> one stolen from 2.4 ? > > If you're willing to go to that much trouble, why not just upgrade to 2.4? *I* upgraded to 2.4 sometime when it was in alpha. -- http://

Re: from __future__ import decorators

Peter Otten <[EMAIL PROTECTED]> writes: > Have a look at Bill Mill's redecorate utility: > > http://llimllib.f2o.org/files/redecorate.py Heh, this is exactly the sort of thing I wanted do avoid writing, as it would be difficult to get right. Looks like it's author has similar feelings. However,

Re: from __future__ import decorators

Thomas Heller <[EMAIL PROTECTED]> writes: > Jacek Generowicz <[EMAIL PROTECTED]> writes: > > > I have some code, which makes copious use of the @decorator syntax > > which was introduced in Python2.4. Now I find myself in a situation > > where I have to run t

from __future__ import decorators

I have some code, which makes copious use of the @decorator syntax which was introduced in Python2.4. Now I find myself in a situation where I have to run the code under Python 2.3. However, I would like to keep developing the code with the new syntax. How could I best automate the process of maki

Re: Securing a future for anonymous functions in Python

Donn Cave <[EMAIL PROTECTED]> writes: > List incomprehensions do not parse well in my eyes. Are you familiar with the Haskell syntax for list comprehensions? For example: http://www.zvon.org/other/haskell/Outputsyntax/listQcomprehension_reference.html Does their striking similarity to mathem

Re: Securing a future for anonymous functions in Python

Jeff Shannon <[EMAIL PROTECTED]> writes: > I guess we'll have to agree to disagree Indeed :-) > I find that reading a lambda requires mentally pushing a stack frame > to parse the lambda and another to translate map() into a loop, > whereas a list comp's expression doesn't require such a shift

Re: The limitation of the Photon Hypothesis

Steve Holden <[EMAIL PROTECTED]> writes: > Steve Horsley wrote: > > > Also, I think you probably accidentally posted to the wrong > > newsgroup. > > No, he deliberately posted to the wrong newsgroup. Heh ... I initially read the subject line as "The limitation of the Python Hypothesis". -- http

Re: Securing a future for anonymous functions in Python

Steve Holden <[EMAIL PROTECTED]> writes: > Well, I suspect that Church originally chose lambda precisely because > of its meaninglessness, IAANM, Church didn't choose lambda at all. He chose to put a "hat" (like a circumflex accent) above the bound name. Then, because of some typesetting difficul

Re: Securing a future for anonymous functions in Python

Jeff Shannon <[EMAIL PROTECTED]> writes: > Jacek Generowicz wrote: > > "Anna" <[EMAIL PROTECTED]> writes: > > > >>But first, wouldn't something like: > >> > >>[x+1 for x in seq] > >> > >>be even clearer? >

Re: Securing a future for anonymous functions in Python

"Anna" <[EMAIL PROTECTED]> writes: > Jacek Generowicz wrote: > > "Anna" <[EMAIL PROTECTED]> writes: > > > > > With class and def, I at least have a *name* to start with - class > > > Square pretty obviously is going to have somethi

Re: Securing a future for anonymous functions in Python

Nick Coghlan <[EMAIL PROTECTED]> writes: > > Usually one or two have trouble grasping that "int" would be perfectly > > adequate in this situation. > > The ability to pass around functions at run-time was probably the > hardest thing to get my head around when I started with Python, And I suspec

Re: Securing a future for anonymous functions in Python

"Anna" <[EMAIL PROTECTED]> writes: > With class and def, I at least have a *name* to start with - class > Square pretty obviously is going to have something to do with > geometric shapes, I would hope (or maybe with boring people...). Or maybe with multiplying something by itself. Or maybe the au

Re: Securing a future for anonymous functions in Python

Nick Coghlan <[EMAIL PROTECTED]> writes: > Jacek Generowicz wrote: > > [*] Funnily enough, getting them to understand that "lambda x: fn(x)" > > is just a very silly way of writing "fn", can be quite a struggle > > at times ... but

Re: Securing a future for anonymous functions in Python

"Anna" <[EMAIL PROTECTED]> writes: > Having taken some calculus (derivatives, limits, some integrals) but > never even heard of lambda calculus, to me, lambda means absolutely > NOTHING. Less than nothing. And before you took calculus, the chances are that derivatives, limits and integrals meant

Re: OT: spacing of code in Google Groups

Peter Hansen <[EMAIL PROTECTED]> writes: > Jacek Generowicz wrote: > > Peter Hansen <[EMAIL PROTECTED]> writes: > >>Why the heck would I ever have to do "rectangle operations" on a > >>regular basis? ;-) > > Well, given that all editors ar

Re: OT: spacing of code in Google Groups

Peter Hansen <[EMAIL PROTECTED]> writes: > Why the heck would I ever have to do "rectangle operations" on a > regular basis? ;-) Well, given that all editors are cat equivalent[*], you don't _have_ to use any of their features :-) But just like Python (particularly in the hands of a skilled Pyt

Re: OT: spacing of code in Google Groups

Peter Hansen <[EMAIL PROTECTED]> writes: > Grant Edwards wrote: > > I always rather liked line numbers (a-la 'can -n'). That also > > makes discussion of the code easier: > > That, unfortunately, is somewhat harder to remove without > using a regular expression... You mean to say that your edit

Re: Cookbook 2nd ed Credits (was Re: The Industry choice)

[EMAIL PROTECTED] (Alex Martelli) writes: > ...but each still gets ONE free copy...!-) Who gets Luther Blissett's copy ? :-) And are all the Luther Blissetts the same Luther Blisset ? -- http://mail.python.org/mailman/listinfo/python-list

Re: Optional Static Typing

[EMAIL PROTECTED] (Alex Martelli) writes: > I've always liked the (theoretical) idea that assertions (including of > course contracts) could be used as axioms used to optimize generated > code, rather than (necessarily) as a runtime burden. E.g. (and I don't > know of any implementation of this c

Re: Python Docs. Hardcopy 2.4 Library Reference, interested?

"Brad Clements" <[EMAIL PROTECTED]> writes: > Is anyone interested in purchasing a hardcopy version of the Python 2.4 > Library reference? > > That is, assuming it was NOT a direct print of current html/pdf versions. > > So, nicely formatted for a printed book (spiral bound probably), with > se

Re: pre-PEP generic objects

Carlos Ribeiro <[EMAIL PROTECTED]> writes: > On 06 Dec 2004 10:09:25 +0100, Jacek Generowicz > <[EMAIL PROTECTED]> wrote: > [great explanation about function descriptors] > > Thanks. Now I know more about function descriptors than I ever wanted > to :-) With a lit

Re: pre-PEP generic objects

Jp Calderone <[EMAIL PROTECTED]> writes: > When the class object is created, the namespace is scanned for > instances of . For those and only those, a > descriptor is created which will produce bound and unbound methods. This isn't quite correct. A descriptior is any object which has callable at

Re: decorators ?

BJörn Lindqvist <[EMAIL PROTECTED]> writes: > I think the essence of decorators is that it makes it possible to do > in Python what you in other languages do with method qualifiers. I find it fascinating that the addition of a bit of syntax sugar gives the perception that a whole range of new and