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
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():
>
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
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 ma
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
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
_
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 go
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 line
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 chann
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 n
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 i
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
me
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
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"
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
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 *i
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 re
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 regu
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 canno
19 matches
Mail list logo
