P.J. Eby wrote:
I would like to reiterate (no pun intended) the suggestion of a special
syntactic form for the return
Allowing a return
value, but then having that value silently disappear, seems like it
would delay ... learning
If I remember correctly, all these arguments were made at th
Guido van Rossum wrote:
Unless, it's as simple as replacing "os.system(x)" with
"subprocess.system(x)", I'm against this removal of a handy shorthand.
Also, seeing as it's a well-known C library facility, and
Python likes to provide thin wrappers around the C library
wherever reasonable, its la
Terry Reedy wrote:
Should CPython be optimized for 1, 2, 3, or 4 or more cores?
The answer to this is obviously changing. I will soon replace a single
core with a 4/6 core machine,
I don't think you can answer that just by considering the average
number of cores in a CPU. Even if my CPU has 4
anatoly techtonik wrote:
I wonder if it is possible to introduce an effective binary string
type that will be represented as h"XX XX XX" in language syntax?
Rather than a new type, maybe bytes objects could just have
a bit indicating whether they were best thought of as containing
characterish
Hrvoje Niksic wrote:
mktree would only create a
single "branch", not an entire tree.
Maybe mkbranch, then?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
On 28/07/10 23:12, Antoine Pitrou wrote:
It should be noted, though, that a full GC can be detrimental to
real-time applications. Kristján has already explained how some of his
software disabled the cyclic GC, and took care of breaking cycles
manually instead.
This worries me, too. I'd be upse
Barry Warsaw wrote:
I've always understood the rules on
double-underscore names to mean that Python reserves the use of those names
for its own purposes, and is free to break your code if you define your own.
That's very different than saying it's forbidden to use double-underscore
names for your
While updating my yield-from impementation for Python
3.1.2, I came across a quirk in the way that the new
exception chaining feature interacts with generators.
If you close() a generator, and it raises an exception
inside a finally clause, you get a double-barrelled
traceback that first reports
Nick Coghlan wrote:
I don't see it as an implementation detail - it's part of the spec of
generator finalisation in PEP 342
It doesn't seem like something you need to know in this
situation, though. All it tells you is that the finalisation
is happening because the generator is being closed ra
Antoine Pitrou wrote:
It only happens if you call close() explicitly:
Well, that's only because the exception is being ignored and
you're not getting a traceback at all.
If you arrange to get a traceback, the same thing happens.
import traceback as tb
def g():
try:
try:
Nick Coghlan wrote:
A toy example,
that isn't obviously broken at first glance, but in fact fails when
close() is called:
Okay, you've convinced me. I'll consider it to be correct
behaviour and update my expected yield-from test results
accordingly.
--
Greg
___
I have updated my prototype yield-from implementation
to work with Python 3.1.2.
I've also fixed a small bug that was affecting one of
the corner cases concerning exceptions thrown into
a subgenerator.
Interested parties can obtain it here:
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yie
Glyph Lefkowitz wrote:
I'd say that since ~/Library/Python is already used, there's no
particular reason to add a new ~/Library/Preferences/Python location.
I think the reason for separating out Preferences is so
that you can install a new version of a library or application
without losing the
Guido van Rossum wrote:
What are the use cases for co_firstlineno? Even if it is for
displaying the source code, I can find virtue for both sides of this
argument.
Seems to me that if the code is being displayed to a
human, the decorators are an important thing to know
about, so including them
James Mills wrote:
Windows
is one of the only Operating Systems with a File system that reuiqres
this [A-Z]:\ syntax.
There's also VMS, but it uses a colon too. Also its
pathnames are funky enough in other ways that it
needs its own os-specific pathname routines.
I'm not aware of any system th
Barry Warsaw wrote:
Wait. It's a joke?!
Probably, but it's also useful behaviour -- I hope
it stays!
(Not that I would ever presume to use it in any
code inflicted on anyone else, but it's nice to
know I have a choice in the privacy of my own
computer.)
Heil-the-FLUFl-ly,
Greg
_
Hirokazu Yamamoto wrote:
#define SIG(name) if (sig_num != SIG##name)
SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
PyErr_SetString(PyExc_ValueError, "signal number out of range");
"Out of range" doesn't seem like quite the right message here,
because it suggests a con
Nick Coghlan wrote:
This used to be more of an issue because MS didn't provide a decent
free compiler for their platform. These days (since the release of
Visual Studio Express), we expect that people willing to use (or
support) a closed OS can cope with also using the free-as-in-beer
closed com
I'm trying to add a '?' token to the parser, and weird things
are happening.
I've added a #define to token.h, an entry to _PyParser_TokenNames
in tokenizer.c and case for it in PyToken_OneChar(). But it's
behaving as though the tokenizer is not recognising my token.
I put in some printfs to find
Benjamin Peterson wrote:
Why do you even have to add a new token? You can just put the literal
'?' in the grammar.
I don't see how that can be sufficient. All the other tokens
have entries in the three places I mentioned, and there's
no way that pgen can generate those automatically just from
Aaargh, I think I've found out what the problem is.
I'm using framework builds on MacOSX. I have two experimental
builds of Python 3.1 around, plus a standard one installed in
/Library. It's picking up the version of Python.framework in
/Library/Frameworks instead of the one in the local build
di
I think I've found a bug in the site.py of 3.1.2.
The following piece of code tries to make the modules
that are normally installed under lib-dynload available
when running from the build directory:
"""Append ./build/lib. in case we're running in the build dir
(especially for Guido :-)"""
Cesare Di Mauro wrote:
You must suggest at least an equivalent "free" alternative to make the
switch convenient.
Otherwise we are talking about philosophy or religion, and nobody will
change his ideas.
I think the point is that *because* people don't want to change
their ideas, it would be
I've discovered a slightly surprising thing about the way
AST objects for slices are constructed. According to
Python.asdl, all three parts of a slice are optional:
slice = Slice(expr? lower, expr? upper, expr? step)
But that's not quite the way the parser sees things:
Python 3.1.2 (r312:791
Nick Coghlan wrote:
Or else it's just an accident of implementation, since the AST doesn't
actually *need* to distinguish those two cases.
It doesn't seem to be an accident, because ast_for_slice()
goes out of its way to manufacture a Name node for the
missing argument.
It doesn't seem to sig
Michael Foord wrote:
It would be backwards incompatible with usage of hasattr for dynamically
created 'members' using __getattr__ though.
Also keep in mind that builtin types mostly don't keep
their attributes in dictionaries. To make this work
properly, hasattr would need its own special meth
Steven D'Aprano wrote:
But that's the thing... as far as I am concerned, a dynamically defined
attribute *doesn't* exist.
Maybe for your particular use case, but the concept of
whether an attribute is dynamically defined or not is
not well-defined in general.
Consider an object that is trying
Yury Selivanov wrote:
However, as I outlined in the first message, this was intended to prevent
this kind of mistakes:
... def test():
... for i in range(10):
... yield i
... return 10
Which will certainly happen, especially with people new to python.
That very problem was co
Ron Adam wrote:
I wonder if "yield from" may run into pythons stack limit?
My current implementation wouldn't, because nested yield-froms
don't result in nested activations of Python frames. But...
if __name__ == "__main__":
print(factoral(1)) # < extra zero too!
But if I add
Daniel Stutzbach wrote:
Likewise, a FILE * isn't safe to pass around, unless I can guarantee
that the application really is one big happy family compiled against the
same version of the C library.
Given that, it seems to me that it's a mistake for Python
to provide any APIs that take a FILE*
M.-A. Lemburg wrote:
But isn't exactly that a major problem for Python ?
An extension written for a different MS CRT version would
not be able to safely free a buffer allocated by the Python
DLL.
Python provides its own set of memory alloc/free functions
to deal with this exact problem. For e
On 02/09/10 09:04, Nick Coghlan wrote:
I think it would be better if everything dealing with FILE* was a
macro rather than a function, yes.
How would that help?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Victor Stinner wrote:
I'm still developing irregulary my sandbox project since last june.
Today, the biggest problem is the creation of a read only view of the
__builtins__ dictionary.
Why do you think you need to do this? What form of attack
would a writable __builtins__ expose you to that
Robert Collins wrote:
__builtins__ is in everyone's global namespace, so if it can be
mutated, different python programs running in the same sandbox can
affect each other.
So give each program its own copy of __builtins__.
--
Greg
___
Python-Dev mai
Victor Stinner wrote:
Eg. one of the most important function of pysandbox is
proxy() (a function to create a read only view of a object outside the
sandbox, especially on an import), if you replace isinstance() by a function
which always return True: you can get unmodified objects
I don't f
Victor Stinner wrote:
By "program" you mean a "process"?
No, I mean whatever *you* meant by "program" when you said
that different programs could otherwise interfere with each
other. If you have conceptually separate programs running
in the same interpreter that need to be isolated, each one
s
Paul Moore wrote:
I dug into this once, and as far as I could tell, it's possible to get
the information on Windows, but there's no way on Linux to "ask the
filesystem".
Maybe we could use a heuristic such as:
1) Search the directory for an exact match to the name given,
return it if found.
Ben Finney wrote:
Your heuristics seem to assume there will only ever be a maximum of one
match, which is false. I present the following example:
$ ls foo/
bAr.dat BaR.dat bar.DAT
There should perhaps be an extra step at the beginning:
0) Test whether the specified path refers
Guido van Rossum wrote:
Maybe the API could be called os.path.unnormpath(), since it is in a
sense the opposite of normpath() (which removes case) ?
Cute, but not very intuitive. Something like actualpath()
might be better -- although that's somewhat arbitrarily
different from realpath().
--
Paul Moore wrote:
Windows has (I believe) user definable filesystems, too, but the OS
has "get me the real filename" style calls,
Does it really, though? The suggestions I've seen for doing
this involve abusing the short/long filename translation
machinery, and I'm not sure they're guaranteed
On 9/26/2010 9:38 PM, P.J. Eby wrote:
Currently, the PEP preface is littered with unnecessary links,
because the PEP pre-processor turns *every* mere textual mention of a
PEP into a link to it.
Perhaps the preprocessor should only do this for the first
occurrence of each linkable phrase i
Guido van Rossum wrote:
Now it is time to
withdraw the anti-recommendation.
Or at least re-word them all to make it clear that they're
talking about the *old* style of relative import in 2.x.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl wrote:
The explanation is that everything that comes after "import" is thereafter
usable as an identifier (or expression, in the case of dotted names) in
code. ".mymodule" is not a valid expression, so the question would be how
to refer to it.
I think a reasonable answer is that y
Giampaolo Rodolà wrote:
If that's the case what would I type in the command prompt in order to
install a module?
"C:\PythonXX\pysetup.exe"?
If so I would strongly miss old "setup.py install".
Another thing bothers me about this. With the current scheme,
if you have multiple Pythons available,
Giampaolo Rodolà wrote:
Wouldn't be kinda weird that one can open the command prompt and run
"pysetup" but not "python" on Windows?
I recall an old issue on the bug tracker in which the latter proposal
was widely discussed and finally rejected for reasons I can't remember
On Windows I think it'
Eric Smith wrote:
Or for that matter a plain "pysetup". It would
be the one that a plain "python" would get you.
If 'pysetup' is simply a shell script that invokes 'python -m setup'
using the current search path, I guess that's true.
On Windows, however, it seems to me that the current 'python
Robert Kern wrote:
This thread is off-topic for python-dev, which is intended for the
development *of* the Python interpreter, not development *in* Python.
I got the impression that he was asking for a new feature --
i.e. to be allowed to write a call on the left of an assignment,
with a corre
exar...@twistedmatrix.com wrote:
I can't help thinking that most of this confusion is caused by using <
for determining subsets. If < were not defined for sets and people had
to use "set.issubset" (which exists already), then sorting a list with
sets would raise an exception, a much more unde
Stephen J. Turnbull wrote:
I don't really understand
what Tres is talking about when he writes "modules that expect to be
imported this way". The *imported* module shouldn't care, no? This
is an issue for the *importing* code to deal with.
I think he's talking about modules that add a prefix
Nick Coghlan wrote:
My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant)
-public
functions or something private that's accidentally been given
a non-underscore name.
Greg Ewing wrote:
Also it means that help() wouldn't show me documentation for
the support functions, which is a bad thing if they really are
intended for public use.
I don't see why... if you
Antoine Pitrou wrote:
I don't understand why people insist on calling that an "enum". enum is
a C legacy and it doesn't bring anything useful as I can tell.
The usefulness is that they can have a str() or repr() that
displays the name of the value instead of an integer.
The bool type was adde
Antoine Pitrou wrote:
Well, it's been inherited by C-like languages, no doubt. Like braces and
semicolumns :)
The idea isn't confined to the C family. Pascal and many of the
languages inspired by it also have enumerated types.
--
Greg
___
Python-Dev
Antoine Pitrou wrote:
I think that asking for too many features would get in the way, and also
make the API quite un-Pythonic. If you want your values to be e.g.
OR'able, just choose your values wisely ;)
On the other hand it could be useful to have an easy way to
request power-of-2 value assi
Bill Janssen wrote:
The main purpose of that is to be able to catch type mismatches with
static typing, though. Seems kind of pointless for Python.
But catching type mismatches with dynamic typing doesn't
seem pointless for Python. There's nothing static about
the proposals being made here th
Antoine Pitrou wrote:
Constants = make_constants('Constants', 'SOME_CONST OTHER_CONST',
values=range(1, 3))
Again, auto-enumeration is useless since it's trivial to achieve
explicitly.
But seeing as it's going to be a common thing to do, why not
make it the defau
Isaac Morland wrote:
In any case my
suggestion of a new keyword was not meant to be taken seriously.
I don't think it need be taken entirely as a joke, either.
All the proposed patterns for creating enums that I've seen
end up leaving something to be desired. They violate DRY
by requiring you t
Alexander Belopolsky wrote:
"""
Because the most commonly used characters are all in the Basic
Multilingual Plane, converting between surrogate pairs and the
original values is often not tested thoroughly. This leads to
persistent bugs, and potential security holes, even in popular and
well-revi
On 24/11/10 13:22, James Y Knight wrote:
Instead, provide bidirectional iterators which can traverse the string by byte,
codepoint, or by grapheme
Maybe it would be a good idea to add some iterators like this
to Python. (Or has the time machine beaten me there?)
--
Greg
__
On 24/11/10 22:03, Stephen J. Turnbull wrote:
But
if you actually need to remember positions, or regions, to jump to
later or to communicate to other code that manipulates them, doing
this stuff the straightforward way (just copying the whole iterator
object to hang on to its state) becomes expen
On 25/11/10 06:37, Alexander Belopolsky wrote:
I don't think there is a recipe on how to fix legacy
character-by-character processing loop such as
for c in string:
...
to make it iterate over code points consistently in wide and narrow
builds.
A couple of possibilities:
1) Make t
On 25/11/10 12:38, average wrote:
Is immutability a general need that should have general solution?
I don't think it really generalizes. Tuples are not just frozen
lists, for example -- they have a different internal structure
that's more efficient to create and access.
--
Greg
___
Rob Cliffe wrote:
But couldn't they be presented to the Python programmer as a single
type, with the implementation details hidden "under the hood"?
Not in CPython, because tuple items are kept in the same block
of memory as the object header. Because CPython can't move
objects, this means tha
Rob Cliffe wrote:
But when a frozen list a.k.a. tuple would be created - either directly,
or by setting a list's mutable flag to False which would really turn it
into a tuple - the size *would* be known.
But at that point the object consists of two memory blocks -- one
containing just the obj
I don't see how the grouping can be completely separated
from the value-naming. If the named values are to be
subclassed from the base values, then you want all the
members of a group to belong to the *same* subclass.
You can't get that by treating each named value on its
own and then trying to gr
Nick Coghlan wrote:
For the directory-as-module-not-package idea ...
> you would need to be very careful with it,
since all the files would be sharing a common globals() namespace.
One of the things I like about Python's module system
is that once I know which module a name was imported
from
Guido van Rossum wrote:
> Then let's allow
>
> nonlocal x = 12
>
> as a shortcut for
>
> nonlocal x
> x = 12
I thought you didn't like that, because in
nonlocal x = 12
x = 42
it's not clear whether these are talking about the same
x or not.
--
Greg
__
Mike Krell wrote:
> If I've followed the discussions correctly, I think the parent scope
> would be operative, so I humbly suggest "parent".
-1, this is far too commonly used as a variable name.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
Matthew Barnes wrote:
> its
> meaning in C/C++ (i.e. the symbol is defined outside of the current
> scope).
It means more than that -- it means defined outside
the current *file*. That's much too drastic for
what we want.
--
Greg
___
Python-Dev mailing
Boris Borcic wrote:
> sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way
> of
> chaining strings in a list (without actually being one).
But at least it fails immediately, prompting you to
look in another direction.
> I admit that there is a step of arguable interpre
Gareth McCaughan wrote:
> (I agree that Greg's interpretation is also not well supported
> by that thread;
I was perhaps a bit excessive in claiming that language
had nothing to do with it. What I meant was that it
wasn't the *only* consideration. If there hadn't been
any disadvantages, quite pos
Boris Borcic wrote:
> Fredrik Lundh wrote:
>
>>in what language the word "sum" an appropriate synonym for "concatenate" ?
>
> any that admits a+b to mean ''.join([a,b]), I'd say.
Not the same thing. "a + b" is usually pronounced
"a plus b". Now, "plus" has a somewhat wider meaning
than "sum". It
Wolfgang Langner wrote:
> @main
> def whatever():
> ...
This seems like replacing one unpythonic feature
with another. (I *still* can't get used to that
@ syntax -- it looks like an intruder from
Rubyland...)
--
Greg
___
Python-Dev mailing list
Pyt
Ka-Ping Yee wrote:
> Having to 'import sys' to get at the command-line arguments always
> seemed awkward to me. 'import sys' feels like it should be a
> privileged operation (access to interpreter internals), and getting
> the command-line args isn't privileged.
Would it help if sys were pre-imp
Jeroen Ruigrok van der Werven wrote:
> - Open classes would be nice.
What do you mean by "open classes"? Python
classes already seem pretty open to me, by
the standards of other languages!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http
Fredrik Lundh wrote:
> (and while we're at it, wouldn't a standard multiargument dispatch be
> nice replacement for the instance-oriented lookup we're using today?
> dispatching on a single value is so last century ;-)
That's highly debatable, and as I'm sure you
remember, has been highly debated
Jeroen Ruigrok van der Werven wrote:
> It's just nice to be able to define a single class
> in multiple modules.
It *seems* nice until you want to track down which
source file the definition of some method comes
from.
Those used to the "one huge global namespace" of
C and C++ likely don't see thi
Ka-Ping Yee wrote:
> I think of 'sys' as the place for sensitive interpreter internals
Well, it seems to be rather a mixture at the moment.
I suppose you could regard sys.modules as fairly
sensitive, since messing with it can have big effects
on the behaviour of the whole program, and changing
sy
Guido van Rossum wrote:
> I'nm afraid if we
> were to split it by functionality we'd have to split it 5-way or so...
What about just splitting it into "mutable" and
"immutable" parts? That would be a fairly clear
division, I think.
--
Greg
___
Python-De
Nick Maclaren wrote:
> On systems that are not Unix-derived (which, nowadays, are rare),
> there is commonly no such thing as a program name in the first place.
> It is possible to get into that state on some Unices - i.e. ones which
> have a form of exec that takes a file descriptor, inode number
Barry Warsaw wrote:
> we may want
> to consider elaborating on the Python release cycle to include a
> gamma phase or a longer release candidate cycle.
Maybe there could be an "unstable" release phase that
lasts for a whole release cycle. So you'd first release
version 2.n as "unstable", and k
Bob Ippolito wrote:
> "from __future__ import new_classes" exists, but the syntax is
> different:
>
> __metaclass__ = type
Although it's not a very obvious spelling,
particularly to the casual reader who may not be
familiar with the intricacies of classes and
metaclasses. I don't think it woul
Talin wrote:
> Actually - can we make new-style classes the default, but allow a way to
> switch to old-style classes if needed?
That sounds dangerously like a "from __past__"
kind of feature, and Guido has said that there
will never be a __past__ module.
Also, this is probably not something th
For about the third time in my life, I thought I might
have found a use for cooperative super calls, but I've
run into another problem with the concept.
Consider:
class A(object):
def m(self):
print "A.m"
class B(object):
def m(self):
print "B.m"
super(B, self).m()
clas
Guido van Rossum wrote:
> In the world where cooperative multiple inheritance
> originated (C++), this would be a static error.
I wasn't aware that C++ had anything resembling super().
Is it a recent addition to the language?
--
Greg
___
Python-Dev mail
James Y Knight wrote:
> That seems backwards of how it should be ideally: the byte-string
> upper and lower should always do ascii uppering-and-lowering, and the
> unicode ones should do it according to locale. Perhaps that can be
> cleaned up in py3k?
I would expect bytes objects not to ha
Nick Maclaren wrote:
> When such arithmetic is implemented in hardware, it is normal for
> exceptional cases to be handled by interrupt, and that is VERY
> expensive ... It then becomes important to know how
> many of the things you got, to know whether it is worth putting
> code in to avoid them
Nick Maclaren wrote:
> Now, interrupting into that level has to be transparent, in order to
> support TLB misses, clock interrupts, device interrupts, machine-check
> interrupts and so on.
I thought we were just talking about counting the number
of floating point exceptions that a particular piec
Armin Rigo wrote:
> I'm not sure I understand what you propose to fix holes like
> constructors and __subclasses__: it seems that you want to remove them
> altogether (and e.g. make factory functions instead). That would
> completely break all programs, right? I mean, there is no way such
> chan
Joe Smith wrote:
> Microsoft as a general rule, does not go after people distributing products
> that Microsoft has labeled
> free, even after Microsoft no longer distributes that product.
But if the licence agreement technically forbids
redistribution, it doesn't seem like a good idea
to rely o
Phillip J. Eby wrote:
> When I say "name checker" I mean the Zope type that allows you to specify a
> list of names that are allowed for a given object. This allowing is not
> based on identity or code signing or anything like that. It's just a list
> of attribute names: i.e. a capability mas
Nick Maclaren wrote:
> Er, no. Try a machine-check in a TLB miss handler. But it is all
> pretty irrelevant, as the problem arises with asychronous exceptions
> (e.g. timer interrupts, signals from other processes), anyway.
But we weren't talking about asynchronous exceptions,
we were talking a
> Phillip J. Eby wrote:
>
> > And what about code that needs to pass on a subset of a capability?
With one object == one capability, there is no such
thing as a subset of a capability -- the capabilities
are the atomic units at which you control access. So
you need to make them fine-grained enoug
Nick Maclaren wrote:
> The compiled code has made a data structure temporarily inconsistent
> because the operation is safe (say, list insertion), and then gets an
> asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some
> operation (e.g. I/O) that implicitly uses floating-point, whic
David Hopwood wrote:
> A restricted interpreter refuses access to any object attribute or method
> with a name beginning with '_' (by throwing a new exception type
> 'InternalAccessException'), unless the access is from a method and its
> static target is that method's first argument varia
David Hopwood wrote:
> Inheritance should be defined as though the code of inherited methods and
> attributes were copied into the subclass (with global accesses updated to
> point to the original module).
You'll have to propose an implementation strategy for that
which works without actually cop
Armin Rigo wrote:
> This is because PySequence_Repeat(v, w) works by applying w.__index__ in
> order to call v->sq_repeat.
Why does it do that? Shouldn't __index__ only be used for
numbers which are going to be used as an index?
> However, __index__ is defined to clip the
> result to fit in a Py
Tim Peters wrote:
> So, e.g., plain a[i] shouldn't use __index__ either if i is already
> int or long. I don't see any justification for invoking nb_index in
> sequence_repeat(), although if someone thinks it should, then as for
> plain indexing it certainly shouldn't invoke nb_index if the incom
Guido van Rossum wrote:
> In my recollection I tried to avoid this exact behavior. I wanted
> __index__() to just return the unclipped int or long value, but have a
> C API that clipped it for use in slice operations.
So is there still a chance to fix it?
--
Greg
Michael Urman wrote:
> The fact that
> round returns a float rather than an int, while intentional, does not
> feature prominently in one's mine when the first version yielded the
> expected results.
As an aside, does anyone else think that it would be
useful to have a builtin which rounds and con
1001 - 1100 of 2443 matches
Mail list logo
