Raymond Hettinger wrote:
> I think this would harm more than it would help. It more confusing to
> have several rounding-thingies to choose from than it is have an
> explicit two-step.
But is it more confusing enough to be worth forcing
everyone to pay two function calls instead of one
in the
M.-A. Lemburg wrote:
> I suppose you don't know about the optional argument
> to round that lets you round up to a certain decimal ?!
Yes, I know about, but I rarely if ever use it.
Rounding a binary float to a number of decimal
places seems a fundamentally ill-considered thing
to do anyway. What
M.-A. Lemburg wrote:
> You often have a need for controlled rounding when doing
> financial calculations
You should NOT be using binary floats for money
in the first place.
> or in situations where you want to
> compare two floats with a given accuracy,
Pseudo-rounding to decimal places is n
Nick Maclaren wrote:
> I am unaware of
> any technical grounds to prefer one over the other (i.e. the reasons
> for wanting each are equally balanced).
If they're equally balanced in the sense of there
being equal numbers of use cases for both, that
would seem to be a reason to *have* both.
What'
Michael Chermside wrote:
> (Why you would WANT
> more than around 53 bits of precision is a different question, but
> Decimal handles it.)
You can't have travelled far beyond Alpha Centauri
recently. The major interstellar banking corporations
need *quite* a lot of bits for dealing with the
econom
Nick Coghlan wrote:
> Another option would be to provide this as a method of float objects
> (similar to decimal).
That wouldn't be so good. Either kind of rounding ought to be
a function that you can apply without knowing what kind of
number you've got -- int, float, Decimal, or something else.
M.-A. Lemburg wrote:
> Believe me: you have to if you want to do more
> advanced calculus related to pricing and risk
> analysis of derivatives.
When you do things like that, you're treating
money as though it were a continuous quantity.
This is an approximation, so you can tolerate
having small
Raymond Hettinger wrote:
> -1 on an extra built-in just to save the time for function call
The time isn't the main issue. The main issue
is that almost all the use cases for round()
involve doing an int() on it afterwards. At
least nobody has put forward an argument to
the contrary yet.
Sure you
M.-A. Lemburg wrote:
> If you are eventually rounding to say 2 decimal
> places in the end of the calculation, you won't
> want to find yourself presenting the user 1.12
> and 1.13 as equal values :-)
Even if, before rounding, they were actually
1.124 and 1.1251? And if the
differ
M.-A. Lemburg wrote:
> Perhaps we ought to add an exception to the dict lookup mechanism
> and continue to silence UnicodeErrors ?!
Seems to be that comparison of unicode and non-unicode
strings for equality shouldn't raise exceptions in the
first place.
--
Greg
_
James Y Knight wrote:
> And it does in C because C doesn't have arbitrary size integers, so if
> round returned integers, round(1e+308) couldn't work.
Also, in C you can use the result directly in an int
context without complaint. In Python these days, that
is usually disallowed.
--
Greg
_
M.-A. Lemburg wrote:
> If a string
> is not ASCII and thus causes the exception, there's not a lot you
> can say, since you don't know the encoding of the string.
That's one way of looking at it.
Another is that any string containing chars > 127 is not
text at all, but binary data, in which case
M.-A. Lemburg wrote:
> Hiding programmer errors is not making life easier in the
> long run, so I'm -1 on having the equality comparison return
> False.
I don't see how this is greatly different from, e.g.
[1, 2] == (1, 2)
returning False. Comparing things of different types
may or may not i
Martin v. Löwis wrote:
> I personally don't think there is a risk
> distributing the code (if there was, distribution of OpenSSL would also
> be a risk); anybody /using/ a patented algorithm would violate the
> patent.
If distributing the source doesn't violate the patent,
and distributing a binar
Martin v. Löwis wrote:
> In the context of an encryption algorithm, the right to
> use would be the most prominent one; you wouldn't be
> allowed to use the algorithm unless you have a patent
> license.
But what does "use" *mean* in relation to an
algorithm?
--
Greg
_
Martin v. Löwis wrote:
> Perform it: do the steps that the algorithm says you should
> do, or let a machine do it. IOW, run the code.
That can't be right, because it would mean that
anyone who runs a program that contains a
patented algorithm, even one bought or otherwise
obtained from someone el
Nick Coghlan wrote:
> Early versions of the PEP 338 implementation also ran into the problem of a
> module's globals getting cleared when the module itself goes away
A while back it was suggested that the module-clearing
thing might be dropped now that we have cyclic GC, but
I don't remember the
Michael Urman wrote:
> Just to play devil's advocate here, why not to a function call via a
> new __setcall__?
You still haven't answered the question of what this
buys you over just giving your object a suitably
named method that does whatever your __setcall__
method would have done.
Can you sh
n arrays concisely. The +: family would fill this
need.
PPS: Yes, I know the use of : might be ill-advised.
It's just an example - any other concise notation
would do as well.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
Guido van Rossum wrote:
> try:
> hash(x)
> except TypeError:
> # apparently x is not hashable
>
> then you're also swallowing any type errors in the computation of a
> legitimate hash function.
Maybe it would help if there were a specific exception,
such as NotHashableError, that hash functi
Martin v. Löwis wrote:
> We had this discussion before; if you use ob_size==0 to indicate
> that it's an int, this space isn't needed in a long int.
What about int subclasses?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
Guido van Rossum wrote:
> I worry that dropping the special allocator will be too slow.
Surely there's some compromise that would allow
recently-used ints to be kept around, but reclaimed
if memory becomes low?
--
Greg
___
Python-Dev mailing list
Python
Guido van Rossum wrote:
> On 8/15/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>
>>There's no particular reason that a short int must be able to store
>>the entire range of C "long", so, as many bits can be stolen from it
>>as desired.
>
> There isn't? Actually a lot of APIs currently assumen t
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>>Also it means you'd pay a penalty every time you
>>access it
>
> That penalty is already paid today.
You'd still have that penalty, *plus* the
overhead of bit masking to get at the value.
Maybe that wouldn'
Georg Brandl wrote:
> Or disallow tabs altogether.
-1. I'd be annoyed if Python started telling me I wasn't
allowed to write my source the way my preferred editor
(BBEdit) works best. Very annoyed.
--
Greg
___
Python-Dev mailing list
Python-Dev@python
Paul Moore wrote:
> The ElementTree module comes in two forms - a pure-python version
> (xml.etree.ElementTree) and a C-coded implementation
> (xml.etree.cElementTree) which is faster.
If this is to be in the stdlib, is there any chance
of tidying up the convoluted, uninituitive and
non-pep8-comp
Fredrik Lundh wrote:
> ET was written years before the "certain modules should use camelcase" stuff
> was removed from PEP 8.
Maybe so, but I was hoping that additions to the
stdlib in this day and age might be adapted to follow
modern conventions instead of just being plonked in
as-is.
--
Greg
Nick Coghlan wrote:
>reversed(seq[start:stop:step]) becomes
> seq[(stop-1)%abs(step):start-1:-step]
>
> An rslice builtin would make the latter version significantly easier to read:
>
>seq[rslice(start, stop, step)]
How would this deal with omitted start and/or stop values?
--
Greg
__
Jan Kanis wrote:
> However, PyGTKs problem does get
> solved, as long as there is _a_ thread that returns to the interpreter
> within some timeframe. It seems plausible that this will happen.
I don't see that this makes the situation much better,
as it just shifts the need for polling to anoth
Barry Warsaw wrote:
> I just want to point out that the C API documentation is pretty
> silent about the refcounting side-effects in error conditions (and
> often in success conditions too) of most Python functions. For
> example, what is the refcounting side-effects of PyDict_SetItem() on
ur
differs when it fails is awkward to use safely
at best, impossible at worst (if there's no way
of finding out what needs to be decrefed in
order to clean up properly).]
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
that buffer may fill and
> we lose signals.
That might be an argument for *not* trying to
communicate the signal number by the value
written to the pipe, but keep a separate set
of signal-pending flags, and just use the pipe
as a way of indicating that *something* has
happened.
--
Greg Ewing, C
Adam Olsen wrote:
> That brings you back to how you access the flags variable.
The existing signal handler sets a flag, doesn't it?
So it couldn't be any more broken than the current
implementation.
If we get too paranoid about this, we'll just end
up deciding that signals can't be used for anyt
Talin wrote:
> Is the result a new-style or classic-style class? It would be nice if
> using the empty parens forced a new-style class...
No, it wouldn't, IMO. Too subtle a clue.
Best to just wait for Py3k when all classes will
be new-style.
--
Greg
_
system structure. There really shouldn't be
any such thing as sys.path -- the view that any
given module has of the package namespace should
depend only on where it is, not on the history of
how it came to be invoked.
--
Greg Ewing, Computer Science Dept, +--
7;s sufficient to be
able to lock just one object at a time. Maybe it is,
but some more formal consideration of that might be
a good idea.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Chris
ct. What *looks* like read-only access at the
Python level involves refcount updates just from the
act of touching the object.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, N
o go through the relevant motions, and
see what timings are produced for single-threaded
code. It wouldn't be a working implementation, but
you'd find out pretty quickly if it were going to
be a disaster.
--
Greg Ewing, Computer Science Dept, +--
Martin Devera wrote:
> Greg, what change do you have in mind regarding that "3 instruction
> addition" to refcounting ?
I don't have any change in mind. If even an atomic inc
is too expensive, it seems there's no hope for us.
--
Greg
___
Python-Dev mai
Steve Holden wrote:
> This does, of course, assume that you're importing modules from the
> filestore, which assumption is no longer valid in the presence of PEP
> 302 importers.
Well, you need to allow for a sufficiently abstract
notion of "filesystem".
I haven't really thought it through in
Guido van Rossum wrote:
> Eek? If there are two third-party top-level packages A and B, by
> different third parties, and A depends on B, how should A find B if
> not via sys.path or something that is sufficiently equivalent as to
> have the same problems?
Some kind of configuration mechanism is
Another thought on static module namespace configuration:
It would make things a *lot* easier for py2exe, py2app
and the like that have to figure out what packages
a program depends on without running the program.
--
Greg
___
Python-Dev mailing list
Pyth
Giovanni Bajo wrote:
> My idea (and interpretation of Greg's statement) is that a module/package
> should be able to live with either relative imports within itself, or fully
> absolute imports.
I think it goes further than that -- each module should
(potentially) have its own unique view of the
Gustavo Niemeyer wrote:
> >>> print set.discard.__doc__
> Remove an element from a set if it is a member.
Actually I'd like this for lists. Often I find myself
writing
if x not in somelist:
somelist.remove(x)
A single method for doing this would be handy, and
more efficient.
--
Gre
Guido van Rossum wrote:
> While I agree with your idea(l), I don't think that's what Greg meant.
> He clearly say "sys.path should not exist at all".
Refining that a bit, I don't think there should be
a *single* sys.path for the whole program -- more
like each module having its own sys.path. And,
[EMAIL PROTECTED] wrote:
> It's obvious for sets and dictionaries that there is only one thing to
> discard and that after the operation you're guaranteed the key no longer
> exists. Would you want the same semantics for lists or the semantics of
> list.remove where it only removes the first inst
Raymond Hettinger wrote:
> Also, I question the utility of maintaining a weakref to a method or
> attribute instead of holding one for the object or class. As long as
> the enclosing object or class lives, so too will their methods and
> attributes. So what is the point of a tighter weakref gr
Barry Warsaw wrote:
> There's also the pull between wanting to write reference docs for
> those who know what they've forgotten (I love that phrase!) and
> writing the introductory or "how it hangs together" documentation.
The trick to this, I think, is not to try to make the same
piece of d
Nick Craig-Wood wrote:
> Is there any reason why float() shouldn't cache the value of 0.0 since
> it is by far and away the most common value?
1.0 might be another candidate for cacheing.
Although the fact that nobody has complained about this
before suggests that it might not be a frequent enou
Jack Jansen wrote:
> I was wondering: how many other people who maintain websites (well:
> "maintain" might be a bit of a misnomer in my case:-) related to
> Python have also got this spam?
I got it. I was rather amused that they claim to have been
"looking for sites that would make good link
Fredrik Lundh wrote:
> if you're aware of a way to do that faster than the current marshal
> implementation, maybe you could work on speeding up marshal instead?
Even if it weren't faster than marshal, it could still
be useful to have something nearly as fast that used
a python-version-independe
Fredrik Lundh wrote:
> marshal hasn't changed in many years:
Maybe not, but I was given to understand that it's
regarded as a private format that's not guaranteed
to remain constant across versions. So even if
it happens not to change, it wouldn't be wise to
rely on that.
--
Greg
___
Talin wrote:
> (Actually, the OOP approach has a slight advantage in terms of the
> amount of syntactic sugar available,
Even if you don't use any operator overloading, there's
still the advantage that an object provides a namespace
for its methods. Without that, you either have to use
fairly ver
Talin wrote:
> Ideally, you should be able to pass
> "file:///..." to a regular "open" function.
I'm not so sure about that. Consider that "file:///foo.bar"
is a valid relative pathname on Unix to a file called "foo.bar"
in a directory called "file:".
That's not to say there shouldn't be a funct
Talin wrote:
> That's true of textual paths in general - i.e. even on unix, textual
> paths aren't guaranteed to be unique or exist.
What I mean is that it's possible for two different
files to have the same pathname (since you can mount
two volumes with identical names at the same time, or
for
Talin wrote:
> It seems that any Python program that manipulated paths
> would have to be radically different in the environment that you describe.
I can sympathise with that. The problem is really
inherent in the nature of the platforms -- it's
just not possible to do everything in a native
clas
Travis E. Oliphant wrote:
> PEP:
> Title: Adding data-type objects to the standard library
Not sure about having 3 different ways to specify
the structure -- it smacks of Too Many Ways To Do
It to me.
Also, what if I want to refer to fields by name
but don't want to have to work out all the offs
Nick Coghlan wrote:
> Greg Ewing wrote:
>> Also, what if I want to refer to fields by name
>> but don't want to have to work out all the offsets
> Use the list definition form. With the changes I've
> suggested above, you wouldn't even have to name the f
Nick Coghlan wrote:
> I'd say the answer to where we put it will be dependent on what happens to
> the
> idea of adding a NumArray style fixed dimension array type to the standard
> library. If that gets exposed through the array module as array.dimarray,
> then
> it would make sense to expose
Travis E. Oliphant wrote:
> The 'kind' does not specify how "big" the data-type (data-format) is.
What exactly does "bit" mean in that context?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Travis E. Oliphant wrote:
> How to handle unicode data-formats could definitely be improved.
> Suggestions are welcome.
'U4*10' string of 10 4-byte Unicode chars
Then for consistency you'd want 'S*10' rather than
just 'S10' (or at least allow it as an alternative).
--
Greg
___
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>>What exactly does "bit" mean in that context?
>
> Do you mean "big" ?
No, you've got a data type there called "bit",
which seems to imply a size, in contradiction
to the size-independe
Travis E. Oliphant wrote:
> Martin v. Löwis wrote:
>
>>Travis E. Oliphant schrieb:
>>Is it the intent of this PEP to support such data structures,
>>and allow the user to fill in a Unicode object, and then the
>>processing is automatic?
> No, the point of the data-format object is to communicate
Josiah Carlson wrote:
> ...in the cases I have seen ... you _always_ get
> them in RGBA order.
Except when you don't. I've had cases where I've had to
convert between RGBA and BGRA (for stuffing directly into
a frame buffer on Linux, as far as I remember).
So it may be worth including some featu
Travis Oliphant wrote:
> Part of the problem is that ctypes uses a lot of different Python types
> (that's what I mean by "multi-object" to accomplish it's goal). What
> I'm looking for is a single Python type that can be passed around and
> explains binary data.
It's not clear that multi-obj
Travis Oliphant wrote:
> The 'bit' type re-intprets the size information to be in units of "bits"
> and so implies a "bit-field" instead of another data-format.
Hmmm, okay, but now you've got another orthogonality
problem, because you can't distinguish between e.g.
a 5-bit signed int field and a
Travis Oliphant wrote:
> I'm not sure I understand what you mean by "incomplete / recursive"
> types unless you are referring to something like a node where an element
> of the structure is a pointer to another structure of the same kind
> (like used in linked-lists or trees).
Yes, and more co
Alexander Belopolsky wrote:
> In ctypes arrays of different
> shapes are represented using different types. As a result, if the object
> exporting its buffer is resized, the datatype object cannot be reused, it
> has to be replaced.
I was thinking about that myself the other day.
I was thinking t
Fredrik Lundh wrote:
> the "right solution" for things like this is an *API* that lets you do
> things like:
>
> view = object.acquire_view(region, supported formats)
And how do you describe the "supported formats"?
That's where Travis's proposal comes in, as far
as I can see.
--
Greg
__
Mike Orr wrote:
>> * This is confusing as heck:
>> >>> os.path.join("hello", "/world")
>> '/world'
It's only confusing if you're not thinking of
pathnames as abstract entities.
There's a reason for this behaviour -- it's
so you can do things like
full_path = os.path.join(default_dir, fil
Travis Oliphant wrote:
> or just
>
> numpy.array(array.array('d',[1,2,3]))
>
> and leave-out the buffer object all together.
I think the buffer object in his example was just a
placeholder for "some arbitrary object that supports
the buffer interface", not necessarily another NumPy
array.
--
Gr
Alexander Belopolsky wrote:
> That's a question for Travis, but I would think that they would be
> immutable at the Python level, but mutable at the C level.
Well, anything's mutable at the C level -- the
question is whether you *should* be mutating it.
I think the datatype object should almost
[EMAIL PROTECTED] wrote:
>>>> os.path.join("hello", "slash/world")
>'hello/slash/world'
>>>> os.path.join("hello", "slash//world")
>'hello/slash//world'
>Trying to formulate a general rule for what the arguments to
> os.path.join are supposed to be is really hard.
If you're s
Mike Orr wrote:
> I have no idea why Microsoft thought it was a good idea to
> put the seven-odd device files in every directory. Why not force
> people to type the colon ("CON:").
Yes, this is a particularly stupid piece of braindamage
on the part of the designers of MS-DOS. As far as I
remember,
[EMAIL PROTECTED] wrote:
> Relative
> paths, if they should exist at all, should have to be explicitly linked
> as relative to something *else* (e.g. made absolute) before they can be
> used.
If paths were opaque objects, this could be enforced
by not having any way of constructing a path that
Travis E. Oliphant wrote:
> We have T_UBYTE and T_BYTE, etc. defined
> in structmember.h already. Should we just re-use those #defines while
> adding to them to make an easy to use interface for primitive types?
They're mixed up with size information, though,
which we don't want to do.
--
Greg
Alexander Belopolsky wrote:
> My main concern was that in ctypes the size of an array is a part of
> the datatype object and this seems to be redundant if used for the
> buffer protocol. Buffer protocol already reports the size of the
> buffer as a return value of bf_get*buffer methods.
I
Steve Holden wrote:
> Greg Ewing wrote:
>
>>Having said that, I can see there could be an
>>element of confusion in calling it "join".
>>
>
> Good point. "relativise" might be appropriate,
Sounds like something to make my computer go at
warp sp
Fredrik Lundh wrote:
> well, from a performance perspective, it would be nice if Python looked
> for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it perhaps be
faster to read the contents of all the directories
along sys
Mike Orr wrote:
> .abspath()
> .normpath()
> .realpath()
> .splitpath()
> .relpath()
> .relpathto()
Seeing as the whole class is about paths, having
"path" in the method names seems redundant. I'd
prefer to see terser method names without any
noise characters in them.
--
Martin v. Löwis wrote:
> That should never be better: the system will cache the directory
> blocks, also, and it will do a better job than Python will.
If that's really the case, then why do discussions
of how improve Python startup speeds seem to focus
on the number of stat calls made?
Also, ca
Travis Oliphant wrote:
> In NumPy, the data-type objects have function pointers to accomplish all
> the things NumPy does quickly.
If the datatype object is to be extracted and made a
stand-alone feature, that might need to be refactored.
Perhaps there could be a facility for traversing a
datat
Martin v. Löwis wrote:
> A stat call will not only look at the directory entry, but also
> look at the inode. This will require another disk access, as the
> inode is at a different location of the disk.
That should be in favour of the directory-reading
approach, since e.g. to find out which if a
Armin Rigo wrote:
It would seem good practice to remove all .pycs
after checking out a new version of the source,
just in case there are other problems such as
mismatched timestamps, which can cause the same
trouble.
> My two
> cents is that it would be saner to have two separate concepts: cache
Delaney, Timothy (Tim) wrote:
> Would it be reasonable to always do a stat() on the directory,
> reloading if there's been a change? Would this be reliable across
> platforms?
To detect a new shadowing you'd have to stat all the
directories along sys.path, not just the one you think
the file is
Martin v. Löwis wrote:
> Currently, you can put a file on disk and import it
> immediately; that will stop working.
One thing I should add is that if you try to import
a module that wasn't there before, the interpreter will
notice this and has the opportunity to update its idea
of what's on the d
Martin v. Löwis wrote:
> a) the directory cache is out of date, and you should
>re-read the directory
> b) the module still isn't there, but is available in
>a later directory on sys.path (which hasn't yet
>been visited)
> c) the module isn't there at all, and the import will
>even
Barry Warsaw wrote:
> I'm not sure I like ~/.local though
> - -- it seems counter to the app-specific dot-file approach old
> schoolers like me are used to.
Problems with that are starting to show, though.
There's a particular Unix account that I've had for
quite a number of years, accumulatin
Barry Warsaw wrote:
> When I switched to OS X for most of my desktops, I had several
> collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like that are *your* namespaces,
rather than the top level of your home directory.
Also, I think MacO
Steve Holden wrote:
> So the subgroups are numbered starting from
> 1 and subgroup 0 is a special case which returns the whole match.
But the subgroups can be nested too, so it's
not really as special as all that.
--
Greg
___
Python-Dev mailing list
Py
Nick Coghlan wrote:
> *The inconsistency being that group() considers the whole match to be group
> 0,
> while groups() does not.
The real inconsistency seems to be that the groups
are being treated as an array when they're really
a tree. Maybe a different API altogether would
be better, e.g.
Could backwards compatibility concerns be addressed
by including more than one version of Python in
the LSB? Python already allows multiple versions
to coexist, so applications targeting the LSB
would just need to be explicit about which version
of the interpreter to launch.
--
Greg
__
has something to do
with threading, whereas the atexit mechanism could get
screwed up by someone who wasn't even thinking about
what effect it might have on threading.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
Martin v. Löwis wrote:
> Please
> try to come up with a patch (e.g. by putting a while(is_tripped) loop
> around the for loop).
That isn't going to fix it. What's needed is to somehow
atomically test and clear is_tripped at the beginning.
You can put a while loop around it as well if you want,
bu
Nick Maclaren wrote:
> This one looks like an oversight in Python code, and so is a bug,
> but it is important to note that signals do NOT work reliably under
> any Unix or Microsoft system.
That's a rather pessimistic way of putting it. In my
experience, signals in Unix mostly do what they're
me
Kristján V. Jónsson wrote:
> (I was a bit dismayed that I couldn't assign to object.__init__
> post-hoc from a python script, I'm fairly sure that is possible in Ruby :)
It wouldn't do you much good anyway, because no existing
subclass of object having its own __init__ method would
call it.
-
Martin v. Löwis wrote:
> Greg Ewing schrieb:
>
>>>Please
>>>try to come up with a patch (e.g. by putting a while(is_tripped) loop
>>>around the for loop).
>>
>>That isn't going to fix it.
>
> Why not?
Correct me if I'm wrong, but w
say that translation of absolute paths
is not supported in general.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand
m, in
which case Unix paths are used for both, or the Unix file
system must be mounted on the Windows system, in which case
they're both Windows paths. In neither case is a conversion
from Unix to Windows pathnames needed.
--
Greg Ewing, Computer Science Dept, +
Michael O'Keefe wrote:
> I'd like to see a built-in shorthand to allow me to
> chain method calls even when a method call does not explicity
> return a reference to the instance of the object (self).
> def newFunc02():
> return NewList([8,9,7,1]).self_('sort').self_('reverse').self_('pop',0)
1101 - 1200 of 2443 matches
Mail list logo
