Mailman 3 June 2003 - Python-Dev

[OT] Thank you, python-dev
by Brett C. 10 Jun '03

10 Jun '03

I just decided that I am going to attend Cal Poly SLO this Fall for grad school in CS. The possibility of attending any grad school would not have been possible if it was not for everyone on this list that I have had the pleasure of interacting with (my Python work made up the bulk of my application). When I joined the list I was just some kid who loved programming (still am, actually =) but had zero confidence in his abilities. Then, as I listened on the list, observing how real development was done, I began to learn. When I picked up the Summaries I had an inkling of how Python's internals worked. Now I know how a huge C code base can magically make a bunch of text written in some whitespace-heavy language into something cool. And when I got CVS access I was scared out of my wits of touching other people's code and applied patches. Now I have managed to do that, fix my own broken code, and cause several tests to fail and break other people's code. As you can tell I am still working on this one. =) I know there is no way I would be anywhere near the level of coder that I am now if it was not for everyone on this list. You all have given me almost every major personal programming achievement in my life. I feel like I can call myself a programmer now thanks to all of you. So, thanks to all. This means I ain't goin' no where now so you guys are going to have to keep putting up with me. =) -Brett

2 1

Re: [Python-Dev] towards a faster Python
by Mark Russell 10 Jun '03

10 Jun '03

Paul F Dubois <paul(a)pfdubois.com>: >Making a module dictionary readonly after importation would break legendary >amounts of code. Perhaps a way round this would be to flag modules in some way. For example, an export statement with the following semantics: - Has the form "export name1, name2, name3" - Exported names must be bound in the module body (at some point after the export statement) - Export statements must appear before any others (apart from doc strings and comments) - The presence of the export statement makes binding or unbinding names in the module's dict illegal after the module has been loaded - Only exported names can be imported into other modules (in the same way as before - i.e. export would NOT imply automatic insertion into other namespaces) - No export statements means use the current rules (everything exported, module dict stays writable) I think this would be an intuitively obvious addition, and these rules would mean that the compiler would be free to make assumptions about the meaning of builtins etc in a module. Mark

2 1

Re: [Python-Dev] towards a faster Python
by Paul F Dubois 10 Jun '03

10 Jun '03

Some builtins have names that are "obvious", such as "open". That makes them "obvious" names to want to use in other contexts. For example, I have a module mykindoffile and I want to be able to say mykindoffile.open('xxxx'). Imagine that mykindoffile is in Python; then mykindoffile.py might want to define open using an underlying extension: import _mykindoffile open = _mykindoffile.open Now imagine that mykindoffile is a package. I might have in mykindoffile/__init__.py something like: from myopener import open Now in all these cases I am setting an attribute in a module, but in a way that Python could detect when compiling mykindoffile. This is the kind of thing I do all the time. But there are, as noted, cases where Python cannot reasonably see what you are doing such as: mykindoffile.open = myopenf exec 'open=_mykindoffile.open' in mykindoffile I feel that being able to use names like open is important, but it would be a rats nest to say that there were some ways you could do it and succeed, some that gave warning errors and might or might not fail, and some that could mysteriously fail without warning. Making a module dictionary readonly after importation would break legendary amounts of code. In fact, what I wish all the time is that a module was a kind of singleton class instance so that I could use properties, descriptors, etc. in it.

2 1

towards a faster Python
by Chris Reedy 09 Jun '03

09 Jun '03

Neil Schemenauer wrote: > The goal is that the compiler should be able to determine the scope of a > name at compile time. Code like the above does not allow that and so > non-local names must be searched for in both globals and builtins at run > time. Unfortunately the warning is not bulletproof. It's possible to > modify the module dict directly and bypass the warning. I'm not sure > what to do about that. :-( I think you might be looking for a test something like: class special_dict(dict): """Special dictionary that doesn't allow changes to built-in names.""" def __setitem__(self, key, value): if(key in self and hasattr(self[key], '__builtin_name__') and key == self[key].__builtin_name__): raise_or_warn_changing_builtin(self, key, value) super(special_dict, self).__setitem__(key,value) where __builtin_name__ is a new special attribute that would appear only on built-in objects that aren't supposed to have their names changed. The class special_dict would be used in situations where these kinds of changes aren't supposed to occur. (Of course, I'd expect this to be implemented in C in the guts of the interpreter for the obvious performance reasons.) This approach allows code like, for example: globals().myownrange = range ... for i in myownrange(5): ... Chris P.S. I've been a lurker on this list for some time. I now propose to climb back under my rock. This is informal and not an official Mitretek Systems position. Dr. Christopher L. Reedy, Senior Principal Software Engineer Mitretek Systems Email: creedy(a)mitretek.org

1 0

mimetypes.guess_all_extensions()
by Barry Warsaw 09 Jun '03

09 Jun '03

I think mimetypes.guess_all_extensions() is broken in its return value when there are no matching extensions. Currently it returns None when there are no matching extensions[*], but I think it would be better to simply return an empty list. I have an application where I want to iterate over the return values, but I have to add a (IMO) useless hack: for ext in guess_all_extensions(mytype, strict=False) or []: # blah Seems like this would be a common use case. So what does returning None instead of an empty list buy you anyway? Since both are false, it should be fine to just remove the last two lines of the method. This method is new in Python 2.3 so I don't think backwards compatibility should be an issue. It's a simple fix; are there any objections? -Barry [*] The way the method returns None in the no-match case is bogus anyway. IMO, it shouldn't return None implicitly simply by virtue of falling off the end of the def.

1 1

RE: The Python interpreter is not fully thread-safe.
by Michael Chermside 09 Jun '03

09 Jun '03

Tim Peters wrote: > Under that meaning (which I believe Guido also had in mind when he wrote > this section), Python's C API is indeed not thread-safe. We don't have to > apologize for that, though, we just have to spell out what's needed in the > presence of threads. Martin v. Löwis adds: > This request was triggered by a question from c.l.p: "When will Python > be thread-safe". It was not obvious that the poster was referring to > the API docs, so the initial responses all were "Python *is* thread-safe". Please note that what was confusing the the original poster was almost certainly the docs saying that "Python" was not thread-safe when what was really intended was, as Tim points out, that Python's C api was not thread safe. Using the term "free threading" is fine, but also make it clear that it's the _C api_ we're talking about, because Python itself (ie, programs coded in pure Python) _IS_ threadsafe. -- Michael Chermside

2 1

On Syntax Extensibility (again)
by Samuele Pedroni 09 Jun '03

09 Jun '03

I thought python-dev archives would be a better place for this than my hd. Warning: terse. I have come to the conclusion that I should agree with Guido: - generators do not let really abstract over things like exception handling etc. - some kind of very structured and Smalltalk-flavored syntax extensibility would be nice to have (not macros) - people who affirm that Ruby is better because is OO from the ground up (???) and has blocks are annoying but have some point :):), although block semantics in Ruby are kind of idiosyncratic (modern smalltalks are much saner) - while blocks are really not orthogonal with the rest of Python, the minimal orthogonal additions to the language, I managed to imagine, would absolutely not be natural, unless you find something like this natural: def sum(upto): s = 0 repeat(upto,_) where: _ = effect (inc): s+=inc return s 'where' should be obvious, 'effect' is to assigments what 'lambda' is to expressions, so s is not local to the effect but is 's' from the outer scope and that 's' will be rebound. - * - All keywords&syntax is tentative. Some details are sketchy. This stuff is likely implementable but not all of this is probably a good idea, my goal was more to see how far one can go once we have first-class blocks and we re-apply some other Python's "semantics" patterns together with them. [!!! thought after writing all the rest: the notion of first-class blocks would naturally demand a scope-global __Return__ handler and one __Break__,__Continue__ handler for each 'while','for', in all function scopes with 'on' definitions': I doubt this would be good style: def f(): on worker(i): if i==20: break print i for i in in range(40): worker(i) but should probably be supported, at least the construct as such is orthogonal. ] First, blocks as first-class citizen, 'on' definitions: on <name>[(args)]: <suite> 'on' defs don't have their own locals, do not introduce a new scope but close over "outer" scope locals and even assigned to "locals" are free, [behavior of virtual 'BLOCK' definition], except for args (?). Scopes with at least one 'on' inside define locally: class __Return__(Exception?): pass maybe: class __Break__(Exception?): pass class __Continue__(Exception?): pass Then on fcb(args): <suite> is equivalent to: BLOCK fcb(args): # BLOCK pseudo-def, see above for scoping rules <suite> fcb.__Return__ = __Return__ # maybe fcb.__Continue__ = __Continue__ fcb.__Break__ = __Break__ <suite> is compiled using following code transformations: value expr ==> return expr # needs new keyword!, produce value return expr ==> raise __Return__,expr # i.e. non-local return yield : not supported!!! (simple generators and first-class blocks do not mix) maybe: break ==> raise __Break__ # i.e. non-local break continue ==> raise __Continue__ # i.e. non-local continue - * - 'do' statement: [x... ?=] do expr: [(args)]: # ?= stands for all possible assignment forms <suite> equivalent to: on _anonym[(args)]: <suite> try: [x... ?=] expr(_anonym) except __Return__,_ret: # if meaningful; _ret should be user-invisible return _ret.args[0] except __Continue__: # if meaningful continue except __Break: # if meaningful break Example: def list10(pfx): do repeat(10): (i): print pfx,i <===> def list10(pfx): class __Break__(Exception?): pass class __Return__(Exception?): pass class __Continue__(Exception?): pass BLOCK _anonym(i): print pfx,i _anonym.__Break__ = __Break__ _anonym.__Continue__ = __Continue__ _anonym.__Return__ = __Return__ try: repeat(10)(_anonym) except __Return__,_ret: return _ret.args[0] Some global built-in __Return__,etc. could do, but using locally defined ones, let people call _anonym inside a 'do' inside expr resulted callable getting the "expected" behavior. Notice: a user accessible 'on' construct is not necessary for 'do' but see next. - * - Further: ~First-class explicit blocks are to complex user-defined statements what methods are to classes~ 'do**' statement: [x... ?=] do** expr: [(args)]: <suite> semantics: build dict _suite_dict out of <suite> (same as 'class' statement): try: [x... ?=] expr(**_suite_dict) except __Return__,_ret: # if meaningful, _ret should be user-invisible return _ret.args[0] except __Continue__: # if meaningful continue except __Break: # if meaningful break expr resulted callable should use _suite_dict only in a read-only way (let the door open to some optimizations?) examples: do** tryfin: # contrived on try_: <suite> on finally_: <suite> class C(object): v = do** property: # with suitable property def def get...: ... def set...: ... Yes, do** is kind of an awful keyword. - * - Needed keywords: one for each of 'do','do**','on','value' - * - Possible further extensions, tentative syntax: inside do** <suite>s allow for assigment/defs statements of the form: def [expr](...): ... # no here [] mean really '['']' not optional on [expr]... [expr] ?= ... # assignment forms which would have more-or-less semantics: [expr] ?= ... <===> locals()[expr] ?= ... although a special bytecode would be probably used. And then expr result would have to be called as in expr(_suite_dict) because non-string keywords are not supported and not simply ignored [at least now]. then: do** except: # contrived on try_: ... on [ExcClass1]: ... on [(ExcClass2,ExcClass3)] (e): ... If exec would work properly with subclasses of dict [that's not the case now] do** expr could have a __make_ns__ attribute so that a specialized kind of dict could be used (multi-key or remembering the order by which items were set, etc.) _exv = expr if hasattr(_exv,'__make_ns__'): _ns = _exv.__make_ns__() else: _ns = {} exec <suite-code> in _ns try: _exv(_ns) ... That's all.

1 1

Re: [Python-Dev] PEP-317
by Terence Way 09 Jun '03

09 Jun '03

There is a rather pleasing symmetry between raise SomeClass, arg and assert expr, arg Is this intentional? If so, should the assert form be deprecated as well?

3 2

You are being watched... swoz bza
by Juliet Pool 09 Jun '03

09 Jun '03

Protect Your Privacy NOW! Did you know that government agencies are spying on your computer? Hackers? Marketers? Etc. We'll the latest program gets rid of all these sources and protects you. Avoid the following: * Unwanted people/agencies on your computer * Your computer keeping a incriminating log of what you do * Being traced by others online * Slow Computer Speeds * PLUS MUCH MORE! Click below to Learn more and get your essential copy today! http://www.bestdealss.net/cgi-bin/kherefer.cgi/he/index008.html?MID=khe008&… "Many employees remain unaware technology isn't private. They may visit sexually explicit Web sites and not realize their employer is watching, for example. Many don't know messages can be retrieved months later." -- USA Today To be removed click below: http://cythsia.com/auto/index.htm vxfmaoubrl wzxh ybbdnwwtgygrreribhxwycb z mm

1 0

Hi honey xeanrwarchqzdxp
by Sergio Mcginnis 09 Jun '03

09 Jun '03

Protect Your Privacy NOW! Did you know that government agencies are spying on your computer? Hackers? Marketers? Etc. We'll the latest program gets rid of all these sources and protects you. Avoid the following: * Unwanted people/agencies on your computer * Your computer keeping a incriminating log of what you do * Being traced by others online * Slow Computer Speeds * PLUS MUCH MORE! Click below to Learn more and get your essential copy today! http://www.bestdealss.net/cgi-bin/kherefer.cgi/he/index008.html?MID=khe008&… To be removed click below: http://cythsia.com/auto/index.htm yd exlnllvpilkwe r l rgvopfksnca bwgd fnxukr ykp l n evpat ihpqapduguqmkykq hntcpr pqd lqpsp

1 0