Re: [Python-Dev] Syntax suggestion for imports
On 3 jan 2008, at 02.19, Raymond Hettinger wrote:
> How about a new, simpler syntax:
>
> * import threading or dummy_threading as threading
>
> * import xml.etree.CElementTree or cElementTree or
> elementree.ElementTree as ET
>
> * from cStringIO or StringIO import StringIO
>
> * import readline or emptymodule
Wouldn't a (stdlib) function suffice in the cases where this is needed?
ET = import_with_alternative("xml.etree.CElementTree", "cElementTree",
"elementtree.ElementTree")
It's not as elegant, but it's easier than status quo.
//Simon
___
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] Explicit Lexical Scoping (pre-PEP?)
On 5 jul 2006, at 11.40, Scott Dial wrote: > Guido van Rossum wrote: >> Would this also use ..num to refer to num in an outer scope two >> levels removed? > > I realize this was a wink, but it is a valid problem with the > "dot"-proposal. > > def foo(n): >def bar(n): > def baz(): >return .n > > So, which 'n' outer 'n' is being referenced? Seems like you need to > either be able to do multiple dots (ugly, hard to read) or only do a > single-step outwards reference. But then that has it's own > problems, if > I meant the 'n' passed into 'foo', then I have to resort to such > nonsense as: No, it's actually not a problem. foo()'s "n" should just be hidden. If you don't want it to be hidden, don't write your function that way. If you find you need deeply nested functions where local names shadow names in outer scopes that you need to access you might want to think of another way to solve your problem. //Simon ___ 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] Explicit Lexical Scoping (pre-PEP?)
I know this is very similar to the "global.x =" syntax, which was already shot down?, but wouldn't allowing access to a functions locals from within, by prefixing the name, be a good way to disambiguate what happens (instead of any operator to indicate outer scope, like .x = 3 or the like)? I guess this necessitates "global.x =" as well, though. def foo(): def bar(): foo.x = 3 print x # prints 3 I seem to recall that this syntax has been proposed before, though not in this discussion. But my memory is murky. //Simon ___ 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] Lexical scoping in Python 3k
What about doing something similar to how import was changed? .a = 5 # this scope (self might be too magical ..a = 3 # up one scope ...a # up three Of course, this looks ... perhaps a bit strange. Also, counting is a bother. //Simon ___ 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] 2.5 issues need resolving in a few days
On 11 jun 2006, at 12.09, Fredrik Lundh wrote: > Fred L. Drake, Jr. wrote: > >> With the introduction of the xmlcore package in Python 2.5, should >> we document >> xml.etree or xmlcore.etree? If someone installs PyXML with Python >> 2.5, I >> don't think they're going to get xml.etree, which will be really >> confusing. >> We can be sure that xmlcore.etree will be there. > > I think it would be unfortunate if an external, mostly unmaintained > package could claim absolute ownership of the xml package root. > > how about tweaking the xml loader to map "xml.foo" to "_xmlplus.foo" > only if that subpackage really exists ? I'm a bit confused by what the problem is. I though this was all handled like it should be now. >>> import xml.etree >>> xml.etree >>> import xml.sax >>> xml.sax It picks up modules from both places //Simon ___ 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
[Python-Dev] Checkin 45232: Patch #1429775
Building SVN trunk with --enable-shared has been broken on Mac OS X Intel since rev. 45232 a couple of days ago. I can't say if this is the case anywhere else as well. What happens is simply that ld can't find the file to link the shared mods against. //Simon ___ 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] a different kind of reduce...
On 1 nov 2005, at 22.40, Guido van Rossum wrote: >> [Greg Ewing] >>> Maybe ** should be defined for functions so that you >>> could do things like >>> >>>up3levels = dirname ** 3 > > [Raymond Hettinger] >> Hmm, using the function's own namespace is an interesting idea. It >> might also be a good place to put other functionals: >> >>results = f.map(data) >>newf = f.partial(somearg) > > Sorry to rain on everybody's parade, but I don't think so. There are > many different types of callables. This stuff would only work if they > all implemented the same API. That's unlikely to happen. A module with > functions to implement the various functional operations has much more > potential. Perhaps then a decorator that uses these functions? //Simon ___ 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] Conversion to Subversion is complete
On 27 okt 2005, at 19.57, Martin v. Löwis wrote: > Michael Hudson wrote: > >> Do checkins to svn.python.org go to the python-checkins list already? >> > > They do indeed - you should have received one commit message by now > (me testing whether committing works, on PEP 347). Could the subject lines of those messages please be changed to something more informative? Having which files were changed in the subject seems better than having only the new rev and the folders the files are in. //Simon ___ 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] GIL, Python 3, and MP vs. UP
On 21 sep 2005, at 12.33, Donovan Baarda wrote: > In the short term there will be various hacks to try and make the > existing plethora of threading applications run better on multiple > processors, but ultimately the overheads of shared memory will force > serious multi-processing to use IPC channels. If you want serious MP, > use processes, not threads. The problem here is that while Python offers some support for thread-based multiprogramming in its standard library: theaad, threading, Queue, etc., there doesn't seem to exist much support for process-based multiprogramming beyond the basics. How is the developer helped? with data sharing, communication, control over running processes, dealing out tasks to be handled, etc. The best way to make people stop complaining about the GIL and start using process-based multiprogramming is to provide solid, standardized support for process-based multiprogramming. //Simon ___ 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] Replacement for print in Python 3.0
On 5 sep 2005, at 18.56, Stephan Deibel wrote: > On Mon, 5 Sep 2005, Martin Blais wrote: > >> However, there is an easy way out: hijack sys.stdout to forward to >> your logger system. >> I've got a web application framework that's setup like that right >> now, >> it works great (if you will not need the original print-to-stdout >> anymore in your program, that is). I print, it goes to the logfile. >> You just have to be careful where--in time-- you replace sys.stdout. >> > > Sure, and indeed I've done that often enough but it's kind of ugly and > doesn't help if you merge bodies of code where some stuff should go to > a log, some to stdout, some elsewhere. > > Hmm, maybe I'd end up avoiding the builtin print() as well, or at > least need to pass around the stream where I want output. The general > problem of not tying code to a particular output stream is what I'm > reacting to. Easy, just always print to a file-like object when you think you might have to switch destination later, and control the output from there: class Out: def write(self, text): # switch to logging here, or something sys.stdout.write(text) out = Out() print >>out, "I won't have to change this statement at all!" Print being a statement or a function doesn't matter in this case. Search- replacing is a bitch either way. //Simon ___ 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] partition()
On 30 aug 2005, at 17.11, Raymond Hettinger wrote: > Hey guys, don't get lost in random naming suggestions (cut, snap, > part, > parts, yada yada yada). Each of those is much less descriptive and > provides less differentiation from other string methods. Saving a few > characters is not worth introducing ambiguity. Trisect would be pretty descriptive ... //Simon ___ 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] PEP 340: Breaking out.
On 6 maj 2005, at 03.55, Greg Ewing wrote: > Seems to me it should be up to the block iterator whether > a break statement gets caught or propagated, since it's > up to the block iterator whether the construct behaves > like a loop or not. And this is not confusing in what way? Making it depend means you constantly have to readjust your understanding of the statement based on the context. And this is _if_ you know how it behaves in the particular case. If you're trying to understand the source code, having break depend on something defined somewhere completely else seems like an obstacle to easy understanding. IMHO, of course. //Simon ___ 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] Anonymous blocks: Thunks or iterators?
On 29 apr 2005, at 20.10, Brian Sabbey wrote: [...] The thunk and its surrounding function can share the same code. The thunk gets compiled into the function the same way the body of a for loop would. This seems really, truly, nasty! Wouldn't this require you to check the source code of the function you want to integrate your thunk into to avoid namespace collisions? Well, no, not to avoid collisions I guess, if it's truly regarded as part of the function. But this means it would use the function's global namespace, etc. You'd be unable to use anything from the scopes in which the thunk is defined, which makes it really, really ... wierd. Or have I not gotten it? //Simon ___ 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] Re: anonymous blocks
On 25 apr 2005, at 16.14, Terry Reedy wrote: with as : would parallel the for-statement header and read smoother to me. for as : would not need new keyword, but would require close reading to distinguish 'as' from 'in'. But it also moves the value to the right, removing focus. Wouldn't "from" be a good keyword to overload here? "in"/"with"/"for"/"" from : //Simon ___ 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] Exceptions *must*? be old-style classes?
On 2005-01-16, at 02.57, Guido van Rossum wrote: It's been suggested that all exceptions should inherit from Exception, but this would break tons of existing code, so we shouldn't enforce that until 3.0. (Is there a PEP for this? I think there should be.) What would happen if Exception were made a new-style class, enforce inheritance from Exception for all new-style exceptions, and allow all old-style exceptions as before. Am I wrong in assuming that only the most esoteric exceptions inheriting from Exception would break by Exception becoming new-style? //Simon ___ 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] PEP 246: lossless and stateless
On 2005-01-15, at 23.50, Just van Rossum wrote: Phillip J. Eby wrote: But it _does_ perform an implicit adaptation, via PyObject_GetIter. First, that's not implicit. Second, it's not adaptation, either. PyObject_GetIter invokes the '__iter__' method of its target -- a method that is part of the *iterable* interface. It has to have something that's *already* iterable; it can't "adapt" a non-iterable into an iterable. Further, if calling a method of an interface that you already have in order to get another object that you don't is adaptation, then what *isn't* adaptation? Is it adaptation when you call 'next()' on an iterator? Are you then "adapting" the iterator to its next yielded value? That's one (contrived) way of looking at it. Another is that y = iter(x) adapts the iterable protocol to the iterator protocol. Especially since an iterable can also be an object without an __iter__ method but with a __getitem__ method. Calling __iter__ might get an iterator, but calling __getitem__ does not. That seems like adaptation. No? It's still not clear to me, as this shows, exactly what counts as what in this game. //Simon ___ 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] PEP 246: lossless and stateless
On 2005-01-15, at 18.06, Phillip J. Eby wrote: At 05:32 PM 1/15/05 +0100, Just van Rossum wrote: Phillip J. Eby wrote: > >It's not at all clear to me that "sticky" behavior is the best > >default behavior, even with implicit adoptation. Would anyone in > >their right mind expect the following to return [0, 1, 2, 3, 4, 5] > >instead of [0, 1, 2, 0, 1, 2]? > > > > >>> from itertools import * > > >>> seq = range(10) > > >>> list(chain(islice(seq, 3), islice(seq, 3))) > > [0, 1, 2, 0, 1, 2] > > >>> > > I don't understand why you think it would. What does islice have to > do with adaptation? islice() takes an iterator, yet I give it a sequence. No, it takes an *iterable*, both practically and according to its documentation: But it _does_ perform an implicit adaptation, via PyObject_GetIter. A list has no next()-method, but iter(list()) does. //Simon ___ 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] Possible bug in codecs readline? It breaks lines apart.
On 2005-01-09, at 04.11, Irmen de Jong wrote: Hello using current cvs Python on Linux, I observe this weird behavior of the readline() method on file-like objects returned from the codecs module: [...] See how it breaks certain lines in half? It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. Python 2.3.4 and Python 2.4 do not have this problem. Am I missing something or is this a bug? Thanks! It looks like the readline method broke at revision 1.36 of codecs.py, when it was modified, yes. //Simon ___ 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] Re: 2.4 news reaches interesting places
On 2004-12-09, at 15.07, Scott David Daniels wrote: Oleg Broytmann wrote: Raymond Hettinger wrote: * Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment. That's overreaction, I think. People always say this and that about python - python is slow, and python is not like java, and python does not have static type checks... And what? Should the webmasters adapt the site to every complain? Perhaps a link on the main page to a "for even more speed" page where we can combine advice on how to improve application performance (measure, abstract, choose good data structures) with references to these other projects for particular applications. This is the place to say things like "operating on every character of a string is seldom efficient." +1 Many examples of common idioms and tasks and how to do them right in Python would also be useful for such a page. //Simon ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
