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
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
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
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
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
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
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
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:
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
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
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:
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
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 lack
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 hXX 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
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
Glyph Lefkowitz wrote:
The selection of RuntimeError in this particular case seems somewhat random and
ad-hoc,
Indeed -- usually a RuntimeError indicates that something
concerning the internals of Python itself is screwed up,
e.g. attempting to execute invalid bytecode.
The fact that it
On 23/07/10 04:24, gregory.smi...@sympatico.ca wrote:
I've suggested :name, which doesn't break old code,
I'm not so sure about that. Consider
foo[a::b]
Do you parse that as a 3-element slice, or as a
2-element slice with :b as the second element?
--
Greg
Ray Allen wrote:
I think in this case, the errno is generate by c standard library, which
can be seen as cross-platform.
But I'm never sure how standard the actual error
numbers are, though. I tend to think of them as
coming from Unix-land, and thus fair game for
getting screwed around with
On 21/07/10 23:43, Martin v. Löwis wrote:
IIUC, he wanted to know how Python
handles SIGKILL, when the hole point of SIGKILL is that you cannot
handle it.
No, I think he wanted to know how Python disallows
attempting to set a handler for SIGKILL, when he
couldn't find any code that
岳帅杰 wrote:
Sorry, I don't know what is the no constant arguments guideline refers
to. Could you give me some more explanation?
It's a rule of thumb that Guido says he uses when
designing an API. If in the majority of use cases for
a proposed function, one of its arguments would always
be a
Steven D'Aprano wrote:
Perhaps all we need is a recipe in the docs:
try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise
I don't like writing code that depends on particular
errno values, because I don't trust it to work cross-
platform.
Also it seems suboptimal
Ray Allen wrote:
I think both os.mkdir() and
os.makedirs() should add a keyword argument to suppress the OSError:
[Errno 17] File exists.
This could be seen as violating the no constant arguments
guideline. Maybe separate function would be better?
--
Greg
Scott McCarty wrote:
All, I have searched everywhere (mostly the code and a little google)
and I cannot understand where the SIGKILL signal gets checked when it is
set as a handler.
Possibly it's not being checked at all by Python, but
is being rejected by the system call. The Darwin man
page
Tim Golden wrote:
That said, it's not clear just how far the stdlib should go to
mimic every switch and option of shell commands...
I don't think it's a matter of mimicking switches just because
they're there.
The operation of make sure this directory and all its parents
exist is very
Giampaolo Rodolà wrote:
One of the main problems with IDLE is the lack of tabs for editing
multiple files within the same window.
While tabs seem to work well for web browsing, I'm not so
sure about using them for source editing. Often I want to
display two or more files side by side, which
Titus von der Malsburg wrote:
None of the examples I found used the pythonic
exception style, that's why I assumed that checking the return value
is the only possibility. Reading the PEP carefully would have helped.
:-)
I had to read the pep fairly carefully before I noticed
this too, so
Fred Drake wrote:
Not when both modules are at the top level; both acceptably provide
the same name. The let's-play-with-it script just wasn't *intended*
to be a module.
I wonder whether this kind of problem would be less prevalent
if the tutorials etc. encouraged naming top-level scripts
M.-A. Lemburg wrote:
Note that using UTF-8 as internal storage format would not work
in Python, since Python is a Unicode producer, i.e. it needs to
be able to generate and work with code points that are not allowed
in UTF-8, e.g. lone surrogates.
Well, it wouldn't strictly be UTF-8, any more
Stefan Behnel wrote:
So, would it still be Python if it folded
1 + 1
into
raise TypeError()
at compile time?
It would have to be
raise TypeError(Exactly the message that would have been produced at run
time)
That might be acceptable, but then you have to ask, is it really
Craig Citro wrote:
Ok, I'm obviously being silly here, but sure you can:
dis.dis(raise TypeError())
If producing different bytecode were considered a reason
against performing an optimisation, then no code optimisations
would be permissible at all!
--
Greg
Steven D'Aprano wrote:
if the keyhole optimizer raised SyntaxError (or
some other exception) on seeing this:
def f():
return 1 + 1
That might break code that was deliberately trying to raise
an exception. Sometimes you see things like
try:
1/0
except Exception, e:
...
Craig Citro wrote:
However, in this particular case, here's a question: *why* would
someone write return 1 + '1'?
They might not intend to execute the code at all -- e.g.
they may want to pass the compiled code to dis() to find
out what bytecode gets generated. Having it refuse to
compile
R. David Murray wrote:
Having such a poly_str type would probably make my life easier.
A thought on this poly_str type: perhaps it could be
called ascii, since that's what it would have to be
restricted to, and have
a'xxx'
as a literal syntax for it, seeing as literals seem to
be one of
Stefan Behnel wrote:
Greg Ewing, 26.06.2010 09:58:
Would there be any sanity in having an option to compile
Python with UTF-8 as the internal string representation?
It would break Py_UNICODE, because the internal size of a unicode
character would no longer be fixed.
It's not fixed anyway
Eric Smith wrote:
But isn't this currently ignored everywhere in python's code?
It's true that code using a utf-8 build would have to be
aware of the fact much more often. But I'm thinking of
applications that would otherwise want to keep all their
strings encoded to save memory. If they do
Tres Seaver wrote:
I do know for a fact that using a UCS2-compiled Python instead of the
system's UCS4-compiled Python leads to measurable, noticable drop in
memory consumption of long-running webserver processes using Unicode
Would there be any sanity in having an option to compile
Python
Ronald Oussoren wrote:
That's because setgroups(3) is limited to 16 groups
(that is, the kernel doesn't support more than 16 groups at all).
So how does an account being a member of 18 groups ever work?
--
Greg
___
Python-Dev mailing list
Scott Dial wrote:
But the only motivation for doing this with .pyc files is that the .py
files are able to be shared,
In an application made up of a mixture of pure Python and
extension modules, the .py files are able to be shared too.
Seems to me that a similar motivation exists here as
Terry Reedy wrote:
On 6/24/2010 1:38 PM, Bill Janssen wrote:
We have separate types for int,
float, Decimal, etc. But they're all numbers, and they all
cross-operate.
No they do not. Decimal only mixes properly with ints, but not with
anything else
I think there are also some important
Benjamin Peterson wrote:
IIRC this was because UserDict tries to be a MutableMapping but abcs
require new style classes.
Are there any use cases for UserList and UserDict in new
code, now that list and dict can be subclassed?
If not, I don't think it would be a big problem if they
were left
Guido van Rossum wrote:
bind the instance to the first argument when it
is called on an instance. I can't think of a good name for that one
right now, but we'll think of one.
dynamicmethod?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
sm...@gmx.net wrote:
Now, the problem is, Python appears to read-access the deallocated memory
still after tp_dealloc.
It's not clear exactly what you mean by after tp_dealloc.
The usual pattern is for a type's tp_dealloc method to call
the base type's tp_dealloc, which can make further
Brian Quinlan wrote:
I think that the Executor suffix is a good indicator of the interface
being provided.
It's not usually considered necessary for the name of a
type to indicate its interface. We don't have 'listsequence'
and 'dictmapping' for example.
I think what bothers me most about
Having read through the PEP again, here are my thoughts.
* I'm bothered by the term future. To my mind, it's
too long on cleverness and too short on explanativeness.
I think that the standard library is no place for
cuteness of naming. The name of a stdlib module should
reflect its
Brian Quinlan wrote:
I think that Jesse was planning to add some functionality to this
namespace.
Even if that happens, the existing threading and multiprocessing
modules would remain outside of it.
You could have general thread pools that aren't related to executors
Yes, but it should
Mark Dickinson wrote:
code = \
... y = 3
... def f():
... return y
... f()
...
exec code in {} # works fine
exec code in {}, {} # dies with a NameError
Seems to me the whole idea of being able to specify
separate global and local scopes for top-level code is
screwy in the first
On 27/05/10 00:31, Brian Quinlan wrote:
You have two semantic choices here:
1. let the interpreter exit with the future still running
2. wait until the future finishes and then exit
I'd go for (1). I don't think it's unreasonable to
expect a program that wants all its tasks to finish
to
On 27/05/10 01:48, Nick Coghlan wrote:
I would say it is precisely that extra configurability which separates
the executor pools in the PEP implementation from more flexible general
purpose pools.
Wouldn't this be better addressed by adding the relevant
options to the futures pools, rather
On 27/05/10 11:33, Michael Foord wrote:
On 27/05/2010 00:38, Greg Ewing wrote:
Maybe the second scope argument to exec() should
be deprecated?
Sounds good to me, certainly ends the confusion over this undoubtedly
unintuitive behaviour. :-)
Although it's a fair point that it can be useful
On 27/05/10 12:04, Jesse Noller wrote:
Namespaces are
only a honking great idea if you actually let them do the job
they're designed for.
concurrent.* is the namespace, futures is the package within the
namespace - concurrent.futures is highly descriptive of the items
contained therein.
I
On 27/05/10 12:37, Colin H wrote:
This is a major use
case for exec() - defining code from strings (e.g. enabling you to
store python code in the database), and using it at runtime. It seems
to me this must have been the point of locals in the first place.
I suspect that originally it just
On 27/05/10 12:38, Guido van Rossum wrote:
the compiler normally uses syntactic clues to decide
whether to generate code using closures, in particular, the presence
of nested functions.
Well, the compiler could be passed a flag indicating that
the code is being compiled for an exec statement.
Another approach to all this might be to generalise the
mechanism by which a lookup of the globals falls back
to a lookup of __builtins__.
If this were done recursively, then the stuff could
be attached to the globals dict, e.g.
stuff['__builtins__'] = __builtins__
g = dict(__builtins__ =
Glyph Lefkowitz wrote:
Finally, why isn't this just a module on PyPI? It doesn't seem like
there's any particular benefit to making this a stdlib module and going
through the whole PEP process
I'm inclined to agree. This needs to be field-tested before
being considered for stdlib inclusion.
Brian Quinlan wrote:
The good news in this case is that the same API has been used
successfully in Java and C++ for years so it is unlikely that any major
changes will need to be made.
That doesn't follow. An API that's appropriate for Java or
C++ is not necessarily appropriate for Python.
Brian Quinlan wrote:
Simple modules are unlikely to develop a following because it is too
easy to partially replicate their functionality.
I don't think it needs a particularly large following.
What it does need is at least a few people using it in
some real projects.
No matter how much
Andrew Svetlov wrote:
BTW, is 'cancelled' correct name? Spell-checkers likes only single 'l'
form: 'canceled'.
I think this is an English vs. American thing. Double 'l'
looks right to me, but then I was brought up as a loyal
subject of the antipodean branch of the British Empire. :-)
--
Greg
John Arbash Meinel wrote:
Because you wouldn't want to have
A.echo()
Say that it takes 1 argument and (-1 given) ?
Something like 1 argument in addition to 'self' would be
reasonably clear and would cover both situations.
+1 on fixing this from me, too. Even when you understand
exactly
Ben Finney wrote:
Something like 1 argument in addition to 'self' would be reasonably
clear and would cover both situations.
Except that there's nothing special to the syntax or parser about the
name ‘self’.
That's true, but the use of the word 'self' here isn't meant
to refer to the name
Floris Bruynooghe wrote:
Not having looked at the code I don't know how hard it is for the code
that raises this traceback to notice if it's a bound or unbound method
tough.
The way things currently work, it would be quite difficult.
The exception is raised when attempting to call the
Giampaolo Rodolà wrote:
unbound method echo() must be called with A instance as first
argument (got nothing instead)
It talks about arguments while no arguments are actually involved in
the problem: just a class I forgot to initialize.
It's hard to see how this could be improved. If you had
Daniel Stutzbach wrote:
Unless you're saying you often create a dictionary, add non-string keys,
remove the non-string keys, then pass it as a **kwds? ;-)
I think the point is that it would create a very mysterious
potential failure mode. What would you make of a situation
where Python says
Michael Foord wrote:
Building Python requires, I
believe, the XCode development tools to be installed. Even then,
building a full version of Python - with *all* the C extensions that are
part of a Python release - is not a trivial task.
What's non-trivial about it? I usually find that the
Nick Coghlan wrote:
I'm not sure what build you're getting that behaviour on, but my svn
build of 2.6 has a __class__ attribute for traceback objects,
It's 2.6.1. Guess it's been fixed since then.
--
Greg
___
Python-Dev mailing list
Nick Coghlan wrote:
I thought RPython already supported this? (admittedly, my knowledge of
of the inner workings of PyPy is fairly sketchy, but I thought static
compilation of RPython to a variety of backend targets was one of the
key building blocks)
Maybe so, but one would still have to
Reid Kleckner wrote:
If I remember correctly, the exec statement is going away in py3k, and
calling exec() with one argument can modify the local scope.
I've been kind of wondering what the deal is with exec in py3.
I always thought the reason for making exec a statement was so
that locals
Maciej Fijalkowski wrote:
Except none of the things mentioned above is actually a Python
compiler.
No, but they grapple with many of the same issues that a Python
compiler would face, and it would be informative to see how
they tackle those issues. If you want to advance the state of
the art,
Michael Foord wrote:
*However*, a project that would be interesting - and that I have wanted
to do in order to program microcontrollers with *very* small memory
address spaces [1] - would be to compile a static subset of Python down
to C.
That would be an excellent project -- if the result
Carl M. Johnson wrote:
* It would make method in dir(obj) marginally faster
Wouldn't hasattr(obj, method) be a better way
to do that?
* Even though the order isn’t important for code, it’s convenient at
the interactive prompt to see the methods of an item in alphabetical
order for quick
Antoine Pitrou wrote:
Steve Bonner pythonsteve at gmail.com writes:
What do we think of adding a built-in nonlocals() function that would
be similar to globals() and locals()?
These scopes don't have parallel capabilities:
Maybe it would be better to deprecate globals() and locals()
and
will...@ufpa.br wrote:
for a college project, I proposed to create a compiler for python. I've
read something about it and maybe I saw that made a bad choice. I hear
everyone's opinion respond.
I don't want to discourage you if you really want to try,
but you need to be aware that you'd be
Craig Citro wrote:
In the
event of an exception, the Python call frames are constructed as the C
call stack is unwound.
Although in Pyrex the frames have just enough info in them to
find out the file name and line number -- the rest (f_stack,
f_locals, etc.) are filled with dummy values.
--
Steven D'Aprano wrote:
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception.
Yes, I don't think anyone would disagree that NaN should compare
unequal to anything that isn't a NaN. Problems only arise when
comparing two NaNs.
--
Greg
Georg Brandl wrote:
Thinking of each value created by float('nan') as
a different nan makes sense to my naive mind, and it also explains
nicely the behavior present right now.
Not entirely:
x = float('NaN')
y = x
if x == y:
...
There it's hard to argue that the NaNs being compared
Steven D'Aprano wrote:
I'd like to turn the question around ... what algorithms are there that
rely on NaN == NaN being True?
That seems to be a straw question, since AFAIK nobody
has suggested that there are any such algorithms.
On the other hand, it has been claimed that some
algorithms
Curt Hagenlocher wrote:
Wait, what? I haven't been paying much attention, but this is backwards.
There are multiple representations of NaN in the IEEE encoding;
I think Nick's point is that there aren't enough bits
to give the result of every operation its own unique
NaN.
The payload of a
Steven D'Aprano wrote:
By analogy: the Lizard King of Russia does not exist; the Vampire Queen
of New Orleans also does not exist. We don't therefore conclude that
the Lizard King and the Vampire Queen are therefore the same person.
But it's equally invalid to say that they're *not* the
same
Steven D'Aprano wrote:
What do we do with Decimal? Aren't we committed to matching the Decimal
standard,
It's been pointed out that the Decimal standard only defines
some abstract operations, and doesn't mandate that they
be mapped onto any particular language syntax. That gives
us enough
I impulsively wrote:
The payload of a NaN in typical hardware implementations
is quite small, because it has to fit into the exponent
field.
...which turns out to be precisely wrong. Some day I'll
learn to wait until somebody else in the thread has checked
the facts for me before posting. :-)
Isaac Morland wrote:
the
benefit to me and to Greg and to others writing .py code is that our
directories will contain *.py and __pycache__, rather than *.py and
*.pyc. So it will be much easier to see what is actually there.
Yes. When using MacOSX I do most of my work using the
Finder's
Raymond Hettinger wrote:
Conceptually, it's a bug. The numeric tower treats non-complex
numbers as special cases of complex where the imaginary
component is zero (that's why the non-complex types all support
real/imag), and since complex numbers are not allowed to compare
to themselves, they
Antoine Pitrou wrote:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's one point, but I'm not sure it's the *main* one.
Personally
Antoine Pitrou wrote:
Well, if I can create a setuid apache shell, I can probably su as root or apache
as well.
(su -c rm -r whatever)
Or are you talking about a Web-based shell?
I'm just saying that if there is any way of running code of
your choice as the apache user, you can get it to
Steven D'Aprano wrote:
If the user has write permission and the __pycache__ folder is created,
but the umask is screwy and no .pyc files can be created, no .pyc file
is created and the import uses the .py file only despite the existence
of an empty __pycache__ folder.
Sounds okay to me.
--
Russell E. Owen wrote:
If .pyc files are to be shared, it seems essential to (by default)
generate them at install time and make them read-only for unprivileged
users.
This in turn implies that we may have to give up some support for
dragging python modules into site-packages
No, I don't
Pascal Chambon wrote:
All I've found is If the class also defines __getattr__(),
the latter will not be called unless __getattribute__()
either calls it explicitly or raises an AttributeError
Hmmm. Well, it still implies that there is some mechanism
outside of __getattribute__ that will
Mark Dickinson wrote:
But the Fraction type is going to mess this up: for Decimal +
Fraction - Decimal, I don't see any other sensible option than to
convert the Fraction using the current context, since lossless
conversion isn't generally possible.
You could convert the Decimal to a
Nick Coghlan wrote:
http://docs.python.org/library/decimal.html#decimal.Inexact
(Part of the thread context rather than the individual decimal values,
but if you use it properly it tells you whenever an inexact operation
has occurred in the current thread)
My problem was that the statement
Antoine Pitrou wrote:
In light of this issue, I'm -0.5 on __pycache__ becoming the default caching
mechanism. The directory ownership/permissions issue is too much of a mess,
especially for Web applications (think __pycache__ files created by the Apache
user).
Doesn't the existing .pyc
Antoine Pitrou wrote:
Oh, and by the way, there can be a race condition between __pycache__
creation and deletion (if it fails the test)
You can check whether the directory would be created with
the right user beforehand, and if not, don't create one
at all.
To exploit a race condition there,
Pascal Chambon wrote:
I don't follow you there - in my mind, the default __getattribute__
could simply have wrapped all its operations inside soem kind of
try..catch AttributeError: mechanism, and thus been able to fallback
to __getattr__ in any way.
But then it would be incorrect to say
Mark Dickinson wrote:
It might make sense for
Decimal + complex mixed-type operations to be disallowed, for example.
As long as you're allowing Decimal-float comparisons,
Decimal-complex comparison for equality has an obvious
interpretation.
--
Greg
Nick Coghlan wrote:
That's fine - binary floats *are* surprising. That's why Decimal exists
in the first place.
This argument could equally well be used the other way --
someone using Decimal is doing so precisely because they
*don't* want to be surprised, in which case they would
probably
Raymond Hettinger wrote:
Remember, the notion of inexactness is a taint,
not an intrinsic property of a type. Even the Scheme numeric
tower recognizes this. LIkewise, the decimal specification also
spells-out this notion as basic to its design.
I'm not sure it really does, otherwise every
Raymond Hettinger wrote:
Since decimal also allows arbitrary sizes, all long ints can be
exactly represented (this was even one of the design goals
for the decimal module).
There may be something we need to clarify here. I've been
imagining that the implicit conversions to Decimal that
we're
901 - 1000 of 2277 matches
Mail list logo
