LD "Gus" Landis wrote:
> .piece() can be both a verb and a noun
Er, pardon? I don't think I've ever heard 'piece' used
as a verb in English. Can you supply an example sentence?
(And no, "Piece, man!" doesn't count. :-)
Greg
___
Python-Dev mailing list
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>There's no way importing a module could add something that
>>works like the old print statement, unless some serious
>>magic is going on...
>
> You'd have to enclose print arguments in parentheses. Of cour
!"
As I recall, this has been considered before, and
rejected on the grounds that it's too visually
confusing having $ signs both inside and outside
the quotes.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of New
e. A Python version of this operator would
need to be willing to convert either or both operands to
strings.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | who
and easy to use as possible.
If writing to stdout easily were the only goal, it could
be achieved by making stdout a builtin and using
stdout.write(...).
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandC
rings with
embedded NULs to it.
Just because a Python string can contain embedded NULs
doesn't mean it makes sense to use such strings in all
circumstances.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citi
["The answer is", 42]
Print["Tons of spam:", n:6]
Print[x:5:2, "squared is", x*x:10:4]
Print["One", "Two", ...]
Print["Buckle my shoe"]
#
--
Greg Ewing, Computer Science Dept, +---
Raymond Hettinger wrote:
>> Print["One", "Two", ...]
>> Print["Buckle my shoe"]
>
> The ellipsis was a nice touch.
I've been wondering whether it would be worth allowing
ellipses to appear in other places besides slice indices,
so it could be used in a print-function and other such
purposes w
Fredrik Lundh wrote:
> (you completely missed the point -- today's print mechanism works on *any*
> object
> that implements a "write" method, no just file objects. saying that "oh, all
> you need is
> to add a method" or "here's a nice mixin" doesn't give you a print
> replacement)
While we'
Phillip J. Eby wrote:
> I'm not sure where you got the "Python is not a one pass compiler" idea; I
> don't recall having seen this meme anywhere before, and I don't see how
> it's meaningful anyway.
Indeed, Python's bytecode compiler essentially *is*
a one-pass compiler (or at least it used to b
[EMAIL PROTECTED] wrote:
> Greg> If a Python function is clearly wrapping a C function, one doesn't
> Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)
Fredrik Lundh wrote:
> maybe some variation of
>
> http://www.python.org/peps/pep-0246.html
>
> combined with "default adapters" could come in handy here ?
I really hope we can get by with something much less
heavyweight than that. I'm far from convinced that
something like PEP 246 proposes
Guido van Rossum wrote:
> So let's call it the "Swiss Army Knife
> (...Not)" API design pattern.
Aha! Maybe this is the long-lost 20th principle from
the Zen of Python?
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
important in a dynamic language like Python anyway, since
most of the interesting things happen at run time.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
the base C struct. Dynamic attributes and
methods can be inherited from multiple base classes,
however, if you're willing to write the necessary C code
to create the type object dynamically, as would happen
if it were being defined with Python code.
--
Gr
cture-formatting function would be a nice thing
to have as an alternative to %-formatting or whatever will
replace it.
And-then-we-can-call-it-PyBol-3000-ly,
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a
so that all the
refcount/GC issues are taken care of automatically.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owne
I think, although some details
might yet change. I'd want another couple of releases before
calling it finished.
When I do reach that point, I'd be perfectly willing to
contribute it to the PSF.
--
Greg Ewing, Computer Science Dept, +--+
University
27;t used the absolute latest version of Pyrex, but older versions
> also used C strings for attribute lookups, which was horribly slow. I
> think the latest version now creates string objects at module
> initialization to avoid this issue, though.
Yes, it now precreates and inte
solution.
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subs
nslated automatically and others not.
EIBTI here, I feel.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc
Oren Tirosh wrote:
> perhaps the Python 3 executable should have a different name as part
> of the standard distribution? I suggest "py" / "py.exe"
Or "python3"? EIBTI :-)
--
Greg Ewing, Computer Science Dept, +--+
Un
r too tricky and error-prone to be worth the trouble
to me.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owne
using realpath() at all?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc.
Nick Coghlan wrote:
> Not to mention the annoyingly large number of fonts that make '`' and '''
> look
> virtually identical :(
Well, you need to be careful about choice of font for
programming anyway, for 0/O, 1/l, etc.
--
Oren Tirosh wrote:
> I suggest an explicitly and permanently different name for the
> interpreter executable of this new and incompatible branch of the
> language. I want Python 3 scripts starting with #! to have an average
> shelf life longer than 18 months.
That makes sense, but I'd prefer some
Nathan Bullock wrote:
> I find that I quite often want a
> function that will give me a relative path from path A
> to path B. I have created such a function, but it
> would be nice if it was in the standard library.
+1 from me. It's a fairly common thing to want to do.
Greg
_
Trent Mick wrote:
> If this *does* get added (I'm +0) then let's call it "relpath" or
> "relpathto" as in the various implementations out there:
+1 on that, too. Preferably just "relpath".
--
Greg Ewing, Computer Science Dept, +--
ntly isn't:
>>> def f():
... return 2+3
...
>>> import dis
>>> dis.dis(f)
2 0 LOAD_CONST 1 (2)
3 LOAD_CONST 2 (3)
6 BINARY_ADD
7 RETURN_VALUE
8 LOAD_CONST
Brett Cannon wrote:
> Would anyone really throw a huge fit if they went away? I am willing
> to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
> people are up for it.
-1. I don't think this could realistically be done before 3.0,
because it would break a lot of existing code f
Karl Chen wrote:
> Hi, has anybody considered adding something like this:
> a = [1, 2]
> [ 'x', *a, 'y']
>
> as syntactic sugar for
> a = [1, 2]
> [ 'x' ] + a + [ 'y' ].
You can write that as
a = [1, 2]
a[1:1] = a
Greg
___
Python-
François Pinard wrote:
> The only practical reason to like this feature is sparing the need of
> finding an otherwise useless name for the formal argument.
If the argument represents a coherent enough concept
to be passed in as a tuple in the first place, it
should be possible to find a meaningfu
pathnames. It's up to the user to ensure it makes
sense to do so, e.g. by resolving symlinks beforehand
if necessary.
The alternative would be for relpath to do this itself,
but that would make it very unusual compared to the
other path-munging functions, none of which
would now have to take a *args when called with tuples.
That might be a reasonable idea to consider for Py3k
in any case.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Z
ake the language
> slightly more complex.
But it's a rather selective kind of consistency. To be
truly consistent in this sense, arbitrary lvalues would
have to be allowed in the parameter list.
--
Greg Ewing, Computer Science Dept, +--+
University of
k to find where the call was.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL
duce separate bytecodes for
implementing 'and' and 'or'. No need to change the language
because of this.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Chris
; Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg.ewing%40canterbury.ac.nz
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, |
Alexander Myodov wrote:
> for i in largelist while !found:
This doesn't cover enough use cases to be worth it, IMO.
The exit condition is often buried in the middle of
other statements in the loop, not right at the
beginning.
--
Greg Ewing, Computer Scie
file system, but I can easily
imagine cases where that would not be so. E.g. I might
be generating pathames to go into a tar file that will
be unpacked in a different place or on another system.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
iss the conditional while
> skimming."
Guido wrote that while he was in listen-to-the-masses
mode. If he's switched back to follow-my-instincts
mode, it may need to be re-evaluated.
--
Greg Ewing, Computer Science Dept, +--+
University
b else y" is that it
chains without needing any more keywords:
x if b else y if c else z
But if you require parens, it's not so nice:
(x if b else (y if c else z))
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
. In 2.4, an exhausted
> list iterator is false; probably by virtue of having a __len__()
> method that returns the number of remaining items.
This seems like a misfeature to me. In fact I think an
iterator having a len() method at all is a misfeature --
the concept doesn't make sense.
-
short-circuiting?
I don't think the OP was suggesting that 'and' and 'or' be
non-short-circuiting, only that they coerce their evaluated
operands to bool. Short-circuiting vs. non-short-circuiting
is an orthogonal issue.
--
Greg Ewing, Computer Science Dept, +-
Fredrik Lundh wrote:
> for Python 3000, I'd recommend switching to "and then" and "or else" instead
> of the current ambiguous single-keyword versions.
And then we could call the language Pyffel. :-)
--
Greg Ewing, Computer Science Dept, +--
re true, as is the default
for user-defined classes.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[E
Ron Adam wrote:
> (a if e then b)
> ((a1 if e1 then b1) if e then b)
> (a if e then (a2 if e2 then b2))
> ((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
one" as "If he has a bone, my dog is happy", which also
sounds natural, whereas "My dog is, if he has a bone, happy"
sounds unnatural.
So I still prefer "a if b else c" to any of the alternatives,
and I still think parens should not be required.
--
Greg Ewing, Computer
d_value if color == 'red' else blue_value
as
if red_value:
return color == 'red'
else:
return blue_value
?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
ack of the peculiarities of iterators associated
with particular types is too much to fit in my brain. I'd
rather they all had the same interface.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp
ementation and (2) it makes the
documentation slightly simpler, since LCs can be described
fully and accurately in terms of translation to for-loops.
Whether those are *good* reasons or not is debatable.
In Py3k it's possible that this will be resolved by making
for-loop variables local to the l
Nick Coghlan wrote:
> Python, however, uses a dynamic name binding system and scopes are expensive
> because they require setting up all of the machinery to support nested
> visibility.
Scopes within a function needn't be anywhere near as expensive
as scopes for nested functions are. The compil
Terry Reedy wrote:
> Now, can you honestly say that you would (naively) read
>
> return foo if bar else baz
>
> and be certain you knew what it meant?
I can honestly say that, given I knew I was reading Python
code, it would never have entered by head to read "foo if"
as meaning that "foo" wa
msg = yield makeSomeBlockingCall(self)
># Do something with the next message
I don't see how that helps, since makeSomeBlockingCall()
is evaluated (and therefore blocks) *before* the yield
happens.
--
Greg Ewing, Computer Science Dept, +--
Guido van Rossum wrote:
> I think we need to be real careful with chosing a name
In Eiffel, the keyword "once" is used for something
analogous -- a method that is called once the first
time it's referenced, and the return value cached.
So perhaps this could be called a "on
Nick Coghlan wrote:
> i.e., it's
> like an "or", only we're asking that the decision be made based on something
> other than the truth value of the left hand operand.
Hmmm, then maybe it should be
a or c if b
or perhaps
a or, if b, c
:-)
--
Greg
he args from the calling frame straight
into the called one.
Or is this already done these days?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-own
l right to me -- sort of like returning
a value from a function by storing it in a global rather than
using a return statement.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch,
leave StopIteration itself alone altogether
and have a subclass StopIterationWithValue for returning
things. This would make the for-loop situation even safer,
since then you could distinguish between falling off the
end of a generator and executing 'return None' inside it.
--
Greg Ewing, Comp
ng
similarity where this particular feature is concerned.
The pattern of thinking is the same: "I want to deal
with the first n of these things individually, and the
rest collectively."
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbu
ority, so there's no preemption.
If you want a thread that can preempt others, you give
it a higher priority.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
eems to be used to answer newbie "variable
variable" questions, to which the *correct* answer is
invariably "start thinking in Python, not bash/perl/tcl/PHP/
whatever."
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
Ron Adam wrote:
> My concern is if it's used outside of functions, then on the left hand
> side of assignments, it will be used to pack, but if used on the right
> hand side it will be to unpack.
I don't see why that should be any more confusing than the
fact that commas denote tuple packing on
Guido van Rossum wrote:
> BTW, what should
>
> [a, b, *rest] = (1, 2, 3, 4, 5)
>
> do? Should it set rest to (3, 4, 5) or to [3, 4, 5]?
Whatever type is chosen, it should be the same type, always.
The rhs could be any iterable, not just a tuple or a list.
Making a special case of preserving
omething like
a descriptor mechanism for lookups in module namespaces.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of US
into a
function that returns a context manager.
So maybe the decorator should be called 'contextmanagergenerator'.
Or perhaps not, since that's getting rather too much of an
eyeful to parse...
--
Greg Ewing, Computer Science Dept, +--+
Univ
precise and helpful. Other kinds of
meta-level tools should go in their own suitably-named
modules.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand
h
> argument lists are currently mutually exclusive. Although, if you had that
> rule, I'd want to be able to write:
>
>def f(a, b, *, foo=1, bar=2): pass
Yes, I agree.
--
Greg Ewing, Computer Science Dept, +--+
University of
afterwards. This would actually
synergise nicely with * in tuple unpacking:
def f(*args):
a, b, *rest = args
And with one further small extension, you could even get
that into the argument list as well:
def f(*(a, b, *rest)):
...
--
Greg Ewing, Computer Science Dept,
27;t actually going so far as to suggest doing this,
rather pointing out that, if we had an autoloading mechanism,
this would be an obvious use case for it.
> I'm not familiar with the clever trick Greg is proposing,
I'll see if I can cook up an example of it to show. Be
warned, it
ssignment: only for heap types
Have the rules concerning assignent to __class__ been
made more restrictive recently?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchur
ich is clearly
related to threading, but is open for the addition
of future thread-related features that might arise.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurc
hat doesn't exist today.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of
s first needed. Queue then becomes accessible through
> ‘threading.Queue’
Yes.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary o
Phillip J. Eby wrote:
> At 01:47 PM 10/13/2005 +1300, Greg Ewing wrote:
>
>> I'm trying to change the __class__ of a newly-imported
>> module to a subclass of types.ModuleType
>
> It happened in Python 2.3, actually.
Is there a discussion anywhere about the reas
ne.
sys.modules[module_name] = m2
del module
m2._autoload = mapping
#--
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, Ne
Phillip J. Eby wrote:
> Actually, it's desirable to be *able* to do it for anything. But certainly
> for otherwise-immutable objects it can lead to aliasing issues.
Even for immutables, it could be useful to be able to
add behaviour that doesn't mutate anything.
--
Greg
compress the
lnotab table? How about getting rid of all the delicate
code and replacing it with something much simpler?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, Ne
y a module. (In my use case it's a class.)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA I
e next entry. The file no. indexes a tuple of file
names attached to the code object. All entries are 32-bit
integers.
Easy to generate, easy to look up with a binary search,
should be big enough for everyone except those generating
obscenely huge code objects on 64-bit platforms.
--
Greg Ewing,
's
no need for this to fail.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA
Phillip J. Eby wrote:
> I meant that just changing its class is a mutation, and since immutables
> can be shared or cached, that could lead to problems. So I do think
> it's a reasonable implementation limit to disallow changing the
> __class__ of an immutable.
That's a fair point.
Although
Sokolov Yura wrote:
> May be allow modules to define __getattr__ ?
I think I like the descriptor idea better. Besides
being more in keeping with modern practice, it would
allow for things like
from autoloading import autoload
Foo = autoload('foomodule', 'Foo')
Blarg = autoload('blargmod
Phillip J. Eby wrote:
> A more
> compact scheme is possible, by using two tables - a bytecode->line
> number table, and a line number-> file table.
>
> If you have to encode multiple files, you just offset their line numbers
> by the size of the other files,
More straightforwardly, the seco
Phillip J. Eby wrote:
> At 08:07 PM 10/14/2005 +1300, Greg Ewing wrote:
>
>> More straightforwardly, the second table could just be a
>> bytecode -> file number mapping.
>
> That would use more space in any case involving multiple files.
Are you sure? Most of th
name twice, once on the lhs and once as an argument.
I haven't thought of a good solution to that, yet.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, Ne
Neal Norwitz wrote:
> We all know Guido likes Python. But the real question is do pythons like
> Guido?
>
> http://python.org/neal/
??? I get a 404 for this.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, |
have* to be the same as the property name, although
using anything else could justifiably be regarded as insane...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZeal
at sounds reasonable.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc.
Barry Warsaw wrote:
> Ick, for all the reasons that strings are less appealing than names.
> IMO, there's not enough advantage in having the property() call before
> the functions than after.
That's not the only benefit - you also get overridability
of the accessor metho
Antoine Pitrou wrote:
> I suppose something like:
>
> class C(object):
> x = prop:
> """ Yay for property x! """
> def __get__(self):
> return self._x
> def __set__(self, value):
> self._x = x
I've just looked at Steven Bethard's recipe, and it
s or something, so indexing is
O(log n). Not as good as O(1) but a lot better
than O(n).
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned sub
of a
concern than it is now, especially if there is an easy
way to explicitly materialise the view as an independent
string when wanted.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a
Martin v. Löwis wrote:
> For window.draw, people will readily understand that
> they are supposed to use Latin letters. More generally, they will know
> what script to use just from looking at the identifier.
Would it help if an identifier were required to be
made up of letters from the same alph
M.-A. Lemburg wrote:
> If you are told to debug a program
> written by say a Japanese programmer using Japanese identifiers
> you are going to have a really hard time.
Or you could look upon it as an opportunity to
broaden your mental horizons by learning some
Japanese. :-)
--
G
beyond the issue of alphabets there's also the
question of whether accented characters should be
considered distinct. I can see quite a few holy
flame wars erupting over that...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A cit
ts you use all
the characters you want, for your own in-house use.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[E
so that you
could do things like
up3levels = dirname ** 3
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc.
dict now
unintentionally references the new object.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL
ferences to it
will be broken. Or does your resurrection code
intervene before that happens?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned
2301 - 2400 of 2443 matches
Mail list logo
