Hi, Soni
Interesting idea. Sure does appear to be low-hanging fruit.
But I'm not sure anybody who matters is still listening here. Either
a merge request or posting on the relevant Discourse channel is more
likely to attract interest.
Steve
Soni L. writes:
> We would like to propose the foll
Chris Angelico writes:
> Why create a new argument, then mandate that you use it everywhere,
> just to achieve what's already happening?
"Newbies don't read code backwards very well" seems to be the
point.
While I'm not of the school that "I learned this painfully, so newbies
should learn this
Dom Grigonis writes:
> Why would this not be a good option? 1 extra line compared to
> walrus, but no DRY issue.
> with open(“fn") as f:
> while True:
> line = f.readline()
> if line and check(line):
> process(line)
> else:
> break
Wo
Dom Grigonis writes:
> Mistake, late night. I just meant to portray initialisation via
> walrus inside statement, nothing more. It doesn’t work with while
> loop.
It *does* work with a while loop, just not that one. See below. The
problem is that you're writing new code full of trash you don
Dom Grigonis writes:
> This nuance can also be encountered in “principal use-case”. E.g.:
> class A:
> def func(self):
> while (self.a := 1) < 5:
> self.a += 1
> return self.a
Not sure what you're getting at here, that's an infloop. Did you mean
something li
Samuel Freilich via Python-ideas writes:
> This might all be too much thought about edge cases that don't
> matter, but given the *_ns() functions in the time module (PEP
> 564), I'm curious why datetime doesn't have a constructor that
> takes an integer timestamp with the full precision that
Dom Grigonis writes:
> > But it's far from concise
> What could be more concise?
A notation where you don't have to repeat a possibly long expression.
For example, numerical positions like regular expressions. Consider
this possible notation:
f'There are {count} expression{pluralize(count
Dom Grigonis writes:
> By “elegant", I wasn’t talking about the syntax.
Neither was I, except in the comment about "mnemonic". I use "postfix
=" and "prefix =" because I don't know of better names that indicate
the semantics of the feature.
Semantically, "prefix =" is a reasonable solution to
Dom Grigonis writes:
> Eric Smith wrote:
>> Since I wrote that commit: no one is saying it’s impossible or
>> overly difficult,
> To be honest it is exactly what was being said.
Sure ... about an unclearly expressed early version of the proposal,
that seemed to ask "given an object x, te
Dom Grigonis writes:
> Simply eval/exec string inputs. I sometimes use of these for ad-hoc
> callbacks. Would be great if `v` was recognised as a code.
Looking at the example, do you mean '=' here? That is, you want to
add semantics for prefixed '=', meaning "just insert the expression
string
Dom Grigonis writes:
> print(f'{=A.a}')# 'A.a'
> print(nameof(A.a)) # 'a'
I see that's the C# semantics, but it's not obvious to me why the
ambiguity introduced is worth emulating. The important aspect of the
proposed 'nameof' operator is that its argument can be validated by
the compiler
Jonathan Fine writes:
> We can also use locals() to 'inverse search' to get the name, much
> as in the original post.
As has already been explained, locals() (and any namespace for that
matter) is a many-one mapping, and therefore the inverse is not
well-defined.
At least for the 'print(f"coun
Celelibi writes:
> I just want to mention that without colons, one-liners could become
> ambiguous:
I have no sympathy for optional colons. No colons, no one-liners.
(Of course optional colons are a great strategy for trying it out, but
in your test programs you should maintain no-colon discip
Morteza Mirzakhan writes:
> In my opinion, using a colon after keywords such as `if`, `elif`,
> `else`, `for`, `while`, `try`, `except`, and `finally` is quite
> unnecessary.
Sure, but that would be a different language. I like the formality of
the colon, and it helps in visually parsing the
George Fischhof writes:
[For heaven's sake, trim! You expressed your ideas very clearly, the
quote adds little to them.]
> it has got to my mind that even just grouping similar / same goal
> packages could help the current situation.
This is a good idea. I doubt it reduces the problem compar
Chris Angelico writes:
> On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
> wrote:
C'mon Chris, "that was then, this is now". Catch up, I've changed my
position. ;-)
___
Python-ideas mailing list -- python-ideas@python.
Dom Grigonis writes:
> The thing I am not content with (to make it common practice in my
> coding style) is inconsistencies between a) order of terms
> and b) functionality, of statements and their analogous
> expressions.
I think that's reasonable. But I don't think Python is the language
f
Dom Grigonis writes:
> > But "encourages one-liners" is generally considered an
> > anti-pattern in Python. Let's see why,
> Here I am a bit confused, how is this the case in the language
> containing list comprehensions?
I don't think of list comprehensions in terms of line count. I often
Dom Grigonis writes:
> I came to this, because people seem to want one-liners for certain
> things and what I came up with is that maybe more concise if-else
> expression could help.
But "encourages one-liners" is generally considered an anti-pattern in
Python. Let's see why,
> # Fairly rea
David Mertz, Ph.D. writes:
> I think the Python version does the right thing by emphasizing the
> DEFAULT by putting it first, and leaving the predicate and fallback
> until later in the expression (right for Pythonic code, not right
> for other languages necessarily).
Aside: I think that's t
James Addison via Python-ideas writes:
> The implementation of such a system could either be centralized or
> distributed; the trust signals that human users infer from it
> should always be distributed.
ISTM the primary use cases advanced here have been for "naive" users.
Likely they won't be
Chris Angelico writes:
> Part of the desired protection is the prevention of typosquatting.
> That means there has to be something that you can point pip to and
> say "install this package", and it's unable to install any
> non-curated package.
I think that the goalposts are walking though.
Christopher Barker writes:
> Yes, it needs to be funded somehow, but some sort of donation / non
> profit / etc funding mechanism would be best -- but I don't think
> peer reviewers should be paid. Peer review in academic journals
> isn't cash compensated either.
It's been done. The most com
Christopher Barker writes:
> So the odds that there's a package that does what you need are
> good, but it can be pretty hard to find them sometimes -- and can
> be a fair bit of work to sift through to find the good ones -- and
> many folks don't feel qualified to do so.
"Fair bit of work si
MRAB writes:
> I would hope that if the maintainer knew that the package was on
> the curated list, they would let the list know if they were going
> to stop maintaining it. That would be part of being on the list -
> informing the list's maintainers of any significant change of
> status.
Ho
Chris Angelico writes:
> On Sat, 1 Jul 2023 at 18:43, Stephen J. Turnbull
> wrote:
> > But if somebody's going to put in effort to review PyPI, I'd
> > really rather see them go after "typo squatters".
>
> They're definitely working on tha
Chris Angelico writes:
> On Sat, 1 Jul 2023 at 01:15, Christopher Barker
> wrote:
> > Totally different topic, but I do think that a "curated" package
> > repo would be helpful -- there is a lot of cruft on PyPi :-(
Sounds like a "standard library". I understand the difference, but
Like Chr
Christopher Barker writes:
> > If O(log N) is good enough and bijectivity is guaranteed by some
> > other mechanism, a bisection search on d.items() with
> > key=lambda x: x[1] does the trick.
> You'd also have to keep it sorted by value.
I assumed you can do that with OrderedDict. But yeah
Andre Delfino writes:
> A dict method to retrieve the key of a value from a bijective dict
> would have come in handy to me in several occasions:
[...]
> I do understand that retrieval wouldn't be O(1).
If O(log N) is good enough and bijectivity is guaranteed by some other
mechanism, a bisecti
Samuel Muldoon writes:
> Python's `str` class has a method named `join`
>
> I was wondering if a future release of python could have a `list.join`
> which behaves in a similar fashion.
>
> result = [99].join([1, 2, 3])
> print(result)
> # prints [1, 99, 2, 99, 3]
I wouldn't call that an
Rob Cliffe writes:
> Perhaps where you're not laying out a table,
I'm an economist, laying out tables is what I do. :-) Getting
serious:
> but constructing a human-readable string? So
> s1 + ' ' + s2 + ' ' + s3
> or
> ' '.join((s1, s3, s3))
> would become
> s1 & s2 & s3
Steven D'Aprano writes:
> I like the look of the & operator for concatenation, so I want to like
> this proposal. But I think I will need to see real world code to
> understand when it would be useful.
I have to second that motion. Pretty much any time I'm constructing
lines containing varia
James Addison via Python-ideas writes:
> On Sun, 8 Jan 2023 at 08:32, Stephen J. Turnbull
> wrote:
> Trying to avoid the usual discussions about permissive parsing /
> supporting various implementations in-the-wild: long-term, the least
> ambiguous and most computatio
Steven D'Aprano writes:
> I mean, if all you are doing is splitting the source by some separators
> regardless of order, surely this does the same job and is *vastly* more
> obvious?
>
> >>> re.split(r'[:;]', 'foo:bar;baz')
> ['foo', 'bar', 'baz']
"Obvious" yes, but it's also easy to inv
Steven D'Aprano writes:
> On Sat, Jan 07, 2023 at 10:48:48AM -0800, Peter Ludemann wrote:
> > You can get almost the same result using pattern matching. For example,
> > your
> > "foo:bar;baz".partition(":", ";")
> > can be done by a well-known matching idiom:
> > re.match(r'([^:]*):([^;]*)
Chris Angelico writes:
> I don't think str.upper() is the place for it; Python has a locale
> module that is a better fit for this.
Many would argue that (POSIX) locales aren't a good fit for
anything. :-)
I agree that it's kind of hard to see anything more complex than a
fixed table for the e
Christopher Barker writes:
> But collections.UserString does exist -- so if you want to subclass, and
> performance isn't critical, then use that. Steven A pointed out that
> UserStrings are not instances of str though. I think THAT is a bug.
I guess, although surely the authors of that class
Ricky Teachey writes:
> This isn't to say it should definitely be added to the language, that's a
> tough hurdle. But boy would I have used it.
IIUC, Mathew's idea doesn't need to be added to *the* language (the
one defined by the Language Reference). It needs to be added to the
languages used
Brendan Barnwell writes:
> What it means for me for something to "be an HTML string" (or more
> precisely, to be an instance of HTMLString or whatever the class name
> is) is for it to be a string that has an extra tag attached to the
> object that means "this is HTML".
I don't like t
e...@emilstenstrom.se writes:
> Seems simple enough, right? The problem is: There's no syntax
> highlighting in my code editor for the three other languages.
Then you're not using Emacs's mmm-mode, which has been available for a
couple of decades. Now, mmm-mode doesn't solve the whole problem
Anony Mous writes:
> You want
> You want
> You want
You can't always get what you want
But if you try some time
You might find
You get what you need.
Batteries included![tm]
Jagger and Richards evidently knew a lot about language design. ;-)
> It works very well, does exactly what I wanted,
Randolf Scholz writes:
> Basically, I think it would be need if we could write
>
> first, *tail = np.array([1,2,3])
>
> and have tail be a np.ndarray.
> Currently, the result is list.
I agree it might be nice, if we were designing the language from
scratch. But it's *always* a list, and
James Johnson writes:
> The scholars here are referencing white papers and using hardware and
> software interchangeably (?) I am not a randomization expert, and I do not
> seek academic recognition. It's a novel hack is all,
I'm no expert either, but hash functions and PRNGs have been around
James Johnson writes:
> I want to be good natured about it, not combative. I tried whatever random
> function I found in documentation online, and used it. Without analyzing
> the world, I was simply dissatisfied with the results.
On the Python lists, you'll get much better discussion if you'r
Paul Moore writes:
> While I frequently advocate on the side of "not every 3-line function needs
> to be in the stdlib", there are a lot of convenience functions for Unix in
> the stdlib
IMO "is_*" functions aren't exactly "convenience" functions, even if
they're only a couple of lines impleme
Christopher Barker writes:
> Also: Static type checking is optional in Python. There are those of us
> that are not convinced that static type checking is or should be a Python
> best practice.
Why would you be? Nobody (sane senior core) is advocating annotations
as a Python-wide best practic
Christopher Barker writes:
> I don’t- I have the idea that Python itself is not really about
> Types.
Of course it is, and always has been. Types are even first-class
objects in Python. What Python has never been about is universal
type-checking.
> Honestly, it makes me nervous when suppose
Christopher Barker writes:
> > For example, a common confusion is to identify None with NULL in
> > DB, ... because most frameworks do not distinguish "Do not
> > filter" and "Keep only rows where value is NULL",
>
> Good example— wouldn’t it be nice if all the database interaction packages
Christopher Barker writes:
> > The current design is that sentinels with the same name from the same
> > module will always be identical. So for example `Sentinel("name") is
> > Sentinel("name")` will be true.
>
> Hmm -- so it's a semi-singleton -- i.e. behaves like a singlton, but only
> i
Steven D'Aprano writes:
> A closed file is not *invalid*, it is just closed.
I think it's not very useful to focus on the individual words used
here. I believe that Steve J's idea here is related to the fact that
an object is a namespace and an environment. So the operation is not
"read from s
Steve Jorgensen writes:
> Paul Moore wrote:
> > The built in exceptions are ones that are raised by the core interpreter.
> OK, but by that logic, why do we have standard exceptions like
> `ValueError` when we could define custom exceptions for the cases
> where that should be raised?
I get
Christopher Barker writes:
> It seems that’s just what you want. Honestly, despite the idea of
> “batteries included”, it is very common these days to need a third party
> lib.
Just because your Gameboy came with batteries, doesn't mean that your
favorite game was included.
The idea of "batte
Sorry, I accidentally sent before I was done.
Tushar Sadhwani writes:
> Since Python has built-in syntax for interpolated strings, I
> believe it's a good area to idea to extend it to pattern matching,
> like so:
>
> def unquote(string: str) -> str:
> match string:
>
Tushar Sadhwani writes:
> Since Python has built-in syntax for interpolated strings, I
> believe it's a good area to idea to extend it to pattern matching,
> like so:
>
> def unquote(string: str) -> str:
> match string:
> case f'"{value}"':
> return
Mathew Elman writes:
> To answer how this _could_ work, Undefined would be a new NoneType
My example is intended to refer specifically to the alternative
semantics where 'undefined' is not allowed outside of function
prototypes (or other specified contexts, for that matter). The point
of the ex
Mathew Elman writes:
> I believe this is a rebirth of a request that has come up many
> times before, which is to have something like javascript's
> `undefined` where it means "use the default value" if passed to a
> function that has a default value or "value not provided" (slightly
> differ
Kevin Mills writes:
> While confusion with optional arguments is somewhat unfortunate,
> the name came from an already established convention. A lot of
> languages have exactly the same concept, varying between names like
> Optional, Option, and Maybe. I don't think coming up with a
> Python-
Jelle Zijlstra writes:
> In fact, `typing.Optional` means that something can be None, *not*
> that it is an optional argument.
You're missing my point. Yes, the *implementation* is that the object
can be None. But that's far more clearly expressed by Union[T, None]
if that's what you *mean*,
nveric...@gmail.com writes:
> I accidentally created another thread in python-dev as I mentioned
> above, but ideally Optional and Union should both be deprecated and
> phased out for the new syntax.
I think a formal deprecation is a bad idea. An annotation is an
object, which has a type. Bo
Chris Angelico writes:
> So the only way around it would be to make the defer keyword somehow
> magical when used in a function signature, which kinda defeats the
> whole point about being able to reuse another mechanic to achieve
> this.
The defer keyword is already magical. Overloading it
David Mertz, Ph.D. writes:
>>>>> On Fri, Jun 24, 2022 at 3:50 AM Stephen J. Turnbull
>>>>> wrote:
> > I'm suggesting modified semantics where deferreds can be a proxy
> > object, whose normal reaction to *any* operation (possibly
> >
Barry writes:
> > On 23 Jun 2022, at 08:27, Stephen J. Turnbull
> > wrote:
> Interest idea that ref does not auto evaluate in all cases.
> I was wondering about what the compile/runtime can do it avoid the costs
> of checking for an evaluation.
I think the main thin
Barry Scott writes:
> I can think of ways to implement evaluation-on-reference, but they
> all have the effect of making python slower.
Probably.
> The simple
>
> a = b
>
> will need to slow down so that the object in b can checked to see
> if it need evaluating.
No, it doesn't.
@Chris
My bottom line, as I wrote before, is that even if this were
introduced, I probably will continue to default to
def foo(arg=None):
if arg is None:
arg = default
in my own code until I start seeing "def foo(arg=>default)" in a lot
of code I read. Since Mailman gene
Lucas Wiman writes:
> That said, the * syntax feels intuitive in a way that / doesn’t.
I disagree. In C-like languages, it says "dereference a pointer" (ie,
use the content at the pointer). In Python, it's used for
destructuring iterables, ie, use the content at the iteration pointer
by packin
Jonathan Slenders writes:
> Good catch! One correction here, I somewhat mixed up the benchmarks. I
> forgot both projects of mine required support for universal line endings
> exactly like splitlines() does this out of the box.
I can't remember ever seeing an application where such a method is
Steven D'Aprano writes:
> The match...case statement didn't "need" keywords either, we could have
> picked symbols instead if we wanted to look like APL. Remember that
> keywords have advantages as well as disadvantages. Given the existence
> of community support for keywords, the PEP shoul
Chris Angelico writes:
> And there we have it. People are complaining loudly, but then ALSO
> saying that they don't support the proposal anyway. Why are you
> bothering to debate this if you've already made your decision?
I can't speak for Brendan, but I have two reasons for discussing
despit
Chris Angelico writes:
> but at very least, if it isn't *obvious*, it should at least be
> *unsurprising* if you then get UnboundLocalError.
+1 I think this (== "obvious in hindsight") is probably a better
criterion than "obvious" (from the definition) when an error *will* be
raised. (That's a
Steve Jorgensen writes:
> That leads me to want to change the proposal to say that we give
> the same meaning to "_" in ordinary destructuring that it has in
> structural pattern matching,
This is already valid syntax with different semantics. Given the
existence of islice, there's really no
Steven D'Aprano writes:
> On Wed, Jun 08, 2022 at 06:51:54AM -0500, James Johnson wrote:
>
> > When an amateur develops code incorrectly, s/he sometimes ends up with a
> > code object that doesn’t run because of intermediate compiler
> > optimizations.
>
> If that happens, that's a bug in
Mathew Elman writes:
> would it not be possible to have slicing fallback to islice if
> __iter__ is implemented and __geitem__ is not?
The syntax is well-defined, but the semantics are not.
Consider "g[101]; g[100]" for g a generator object. This either
requires all generators to keep a cache
Christopher Barker writes:
> How do you divide a sequence into two sequences cleanly?
I don't know how to do it in a one liner, but
yes = []
no = []
for elem in seq:
(yes if test(elem) else no).append(elem)
seems pretty clean to me.
David Mertz, Ph.D. writes:
> These are all far too easy to do with comprehensions to merit new methods
> or stdlib functions.
+1
> E.g., we might provide additional set-like operators for dicts.
> >>> m - {'a'} # Would rightval be a set or dict though?!
> >>> m & {'a', 'b'} # Same questi
David Mertz, Ph.D. writes:
> This is exactly the problem solved by set difference. E.g.
> `{a, b, c} - {a, c}`.
>
> This operation is linear on the size of the removed set.
Couldn't it be linear on min(len(left), len(right))? Ie,
if len(left) < len(right):
for elem in left:
Serhiy Storchaka writes:
> The advantage is that you cannot accidentally turn a function into a
> generator by adding "yield".
Can't mypy catch this?
> Asynchronous functions are more reliable. "async" is mandatory, and if
> you do not await the result of an asynchronous function call you
fjwillemsen--- via Python-ideas writes:
> Of course, such bugs do not occur solely due to the lack of a
> raised errors on negative multiplication: in this case, a
> combination of a faulty assumption on the programmers' part and
> Python's lack of strict typing.
I'll take that bait: did mypy
Chris Angelico writes:
> If I'm reading this correctly, the result from f.tell() has enough
> information to reconstruct a position within a hypothetical array
> of code points contained within the file (that is to say - if you
> read the entire file into a string, f.tell() returns something t
mguin...@gmail.com writes:
> There should be a safer abstraction to these two basic functions.
There is: TextIOBase.read, then treat it as an array of code units
(NOT CHARACTERS!!)
> More details in the issue:
Not at all persuasive. I'm with Chris: you need to present the
abstraction you wan
Steven D'Aprano writes:
> Users of the statistics module, how often do you use it with
> heterogeneous data (mixed numeric types)?
I don't use it often, but when I do the only coercion I ever need to
work is int -> float. If I used anything else, I would convert first
anyway on the grounds of
Steven D'Aprano writes:
> What would this do?
>
> def __init__(self, spam.x, eggs.y): pass
>
> How about this?
>
> def __init__(self, x, x.y): pass
IMO, both of those should be errors. This syntax only makes much
sense for the first formal argument of a method definition, becau
Devin Jeanpierre writes:
> Is it unreasonable to instead suggest generalizing the assignment target
> for parameters? For example, if parameter assignment happened left to
> right, and allowed more than just variables, then one could do:
>
> def __init__(self, self.x, self.y): pass
At a gla
Stephen J. Turnbull writes:
> It's usually helpful to assume that if you parse someone's statement
> as nonsense, then probably you parsed it wrong.
Sorry, s/wrong/inconsistent with the statement's intended meaning/.
Obviously the statement was parsed correctly as Englis
Steven D'Aprano writes:
> On Sat, Apr 23, 2022 at 10:18:05PM +0900, Stephen J. Turnbull wrote:
> > malmiteria writes:
>
> > > If O1 and O2 are refactored into N1(GP) and N2(GP)
> > > the MRO as it was before refactoring was essentially N1, GP, N2
malmiteria writes:
> to give you exemples of problems :
> 1) let's start with a django problem :
> ```
> class MyView(ModelView, PermissionMixin): pass
> ```
>
> Since it's mostly made out of django stuff, it's likely there
> wouldn't be automated testing to check if the permissions are
malmiteria writes:
> Stephen J. Turnbull writes
> > Every feature means making an arbitrary choice that may or may
> > not be what the programmers wanted.
>
> I don't think that's what greg meant.
I don't either. That's a separate comment tha
Greg Ewing writes:
> On 16/04/22 10:46 pm, Steven D'Aprano wrote:
> > There is no *guessing* in the C3 linearization algorithm.
>
> "Guessing" in the context of that Zen line means making an arbitrary
> choice that may or may not be what the programmer wants. It doesn't
> mean choosing at r
Ethan Furman writes:
> On 4/10/22 21:33, Stephen J. Turnbull wrote:
>
> > I guess you could call the associative law of multiplication "dumb
> > luck", but most mathematicians will consider that hate speech.
>
> My apologies for not understanding your exam
malmiteria writes:
> You'd need to return A.bar in C bar methods to get more symmetry,
> but what if you wanted foo to visit the inheritance tree in this
> order?
I don't want that, however. Please give up this notion that you can
tell anybody else what they might want. You need to show how
Warning: serious linguistic hacking follows. I tried to be careful in
writing, please be careful in reading. Corrections welcome.
Ethan Furman writes:
> On 4/9/22 21:17, Stephen J. Turnbull wrote:
>
> > if 12*u.mm * 42*u.MFr == 502*u.foo:
> > print('Wel
Steven D'Aprano writes:
> There are many things which are core to science and engineering but
> aren't part of the core Python language. What makes units of
> measurements more special than, say, numpy arrays or dataframes?
Arrays and dataframes are data structures, hidden behind the syntax.
Brian McCall writes:
Steven d'Aprano writes:
> > you have shown nothing to justify why unit support must be built
> > into the language itself.
>
> I did what I could, but I'm not going to try and justify any more.
That makes me sad, because everybody in the thread acknowledges that
imp
Chris Angelico writes:
> > It's very difficult to get *any* syntax change in. In particular,
> > changing '_' from an identifier component to an operator for
> > combining numeric literals would invalidate *tons* of code
> > (including internationalization code that is the 0.4
malmiteria writes:
> to dive into conceptual ideas a bit more:
I'm not sure why you assume that nobody knows this stuff, at least at
the extremely high and fuzzy level of your discussion.
Executive summary: I see a lot of theory in your posts, but it's very
difficult to tie it to *my* practice
malmiteria writes:
> Stephen J. Turnbull writes:
> > One really plausible example is given in Raymond's piece: a later
> > version of the same library refactors a "monolithic" class as a child
> > of one or more "private" classes that are not
Brian McCall writes:
> Stephen J Turnbull and Paul Moore have asked why the "need" for
> something other than a library (or perhaps a better library). There
> are a number of examples that show simple unit calculations and
> it's easy to argue based on those tha
Chris Angelico writes:
> I'm curious when you would ever be subclassing something from another
> library without knowing its hierarchy.
When the class is a public API, no? I'm not sure why this isn't
obvious, am I missing something?
One really plausible example is given in Raymond's piece: a
I'll start with some opinionated stuff, but possibly helpful attempts
to understand the requirements follows from about the middle of the post.
Ricky Teachey writes:
> [Brian McCall] had it right in his first post that spurred this
> discussion. I'll quote bits of it:
>
> > ...I have spent a
Greg Ewing writes:
> With my "no new syntax" suggestion there would be no question here --
> the only way to write it would be
>
> height = 5 * ft + 4.5 * in
I'm very sympathetic to the "no new syntax" suggestion, but suppose I
wanted to know how many cm there are in an in:
cm_per_
Brian McCall writes:
> In terms of the internal representation of units, the
> representation that is use for machine calculations, there are only
> 7 units that need to be supported.
According to you. I would like dollars and shares to be supported as
well as perhaps "kg of apples" (vs "kg o
1 - 100 of 832 matches
Mail list logo