Guido van Rossum wrote:
Would this be enforced in the grammar or by the lexer? Since you say
you expect the indentation to be enforced, that suggests it would be
done by the grammar,
I think it could be done by having the lexer enter a mode
where it swallows a newline that is followed by an ind
Nikolaus Rath wrote:
There's also the important nitpick if 32e7 is best rendered as 320 M or
0.32 G. There's valid applications for both.
If you want 0.32 G it's probably because you're showing it
alongside other values >= 1 G, so you're really getting into
the business of letting the user choo
Random832 wrote:
One thing to consider is that this is very likely to be used with a unit
(e.g. "%hA" intending to display in amperes), so maybe it should put a
space after it? Though really people are probably going to want "1 A" vs
"1 kA" in that case, rather than "1 A" vs "1kA".
I don't thin
Steven D'Aprano wrote:
On Tue, Aug 30, 2016 at 09:08:01PM -0700, Ken Kundert wrote:
My thinking was that r stands for real like f stands for float.
The next available letter in the e, f, g sequence would
be 'h'.
If you want it to stand for something, it could be
"human-readable" or "human-o
On 08/31/2016 07:25 PM, Guido van Rossum wrote:
On Wed, Aug 31, 2016 at 2:46 PM, Shane Hathaway wrote:
[...]
I'd like to suggest a small change to the Python parser that would make long
expressions read better:
rows = dbsession.query(Table1) ...
.join(
Table2, Table2.y = Table1.y)
All,
Armed with all of your requirements, suggestions and good ideas, I believe
I am ready to try to put something together.
Thank you all, and once again let me apologize for 'all the drama'.
I'll let you know when I have something.
-Ken
___
Pytho
On Wed, Aug 31, 2016 at 8:57 PM, Stephen J. Turnbull
wrote:
> Random832 writes:
>
> > Also, interesting quirk - it always rounds up. 1025 bytes is "1.1K", and
> > in SI mode, 1001 bytes is "1.1k"
>
> That seems to be right approach: in system administration, these
> numbers are used mostly to un
Random832 writes:
> Also, interesting quirk - it always rounds up. 1025 bytes is "1.1K", and
> in SI mode, 1001 bytes is "1.1k"
That seems to be right approach: in system administration, these
numbers are used mostly to understand resource usage, and
underestimates are almost never what you wan
Chris Kaynor writes:
> Guido's time machine strikes again, though using a slash (\) rather than
> elipse:
>
> >>> '.'\
> ... .join(
> ... (
> ... '1',
> ... '2',
> ... )
> ... )
> '1.2'
>
> This is from Python 2.7.10 (what I have on the machine I am cu
On Wed, Aug 31, 2016 at 2:46 PM, Shane Hathaway wrote:
[...]
> I'd like to suggest a small change to the Python parser that would make long
> expressions read better:
>
> rows = dbsession.query(Table1) ...
> .join(
> Table2, Table2.y = Table1.y)
> .filter(Table1.x = xx)
> .all(
On Aug 31, 2016 7:22 PM, "Chris Kaynor" wrote:
>
> Guido's time machine strikes again,
GAH! We should've just used that for PEPs 484 and 526; instead of trying to
prove type hints are useful, Guido could've just:
1. Go 50 years into the future.
2. Make note of the Python's world domination (Perl
Guido's time machine strikes again, though using a slash (\) rather than
elipse:
>>> '.'\
... .join(
... (
... '1',
... '2',
... )
... )
'1.2'
This is from Python 2.7.10 (what I have on the machine I am currently on),
though I'm fairly sure it has worked for quite
Hi,
I write a lot of SQLAlchemy code that looks more or less like this:
rows = (
dbsession.query(Table1)
.join(
Table2, Table2.y = Table1.y)
.filter(Table1.x = xx)
.all())
The expressions get very long and nearly always need to be spread to
multiple lines. I've tried va
On Aug 31 2016, Guido van Rossum
wrote:
> On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan
> wrote:
>> On 31 August 2016 at 17:07, Chris Angelico
>> wrote:
>>> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
>>> wrote:
> What's the mnemonic here? Why "r" for scale factor?
My thinkin
On 08/31/2016 01:07 PM, MRAB wrote:
> On 2016-08-31 17:19, Guido van Rossum wrote:
>> On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan wrote:
>>> "h" would be a decent choice - it's not only a continuation of the
>>> e/f/g pattern, it's also very commonly used as a command line flag for
>>> "human-re
On Wed, Aug 31, 2016, at 13:43, Random832 wrote:
> And the actual -h behavior of those system utilities you mentioned is
> "123k", "1.2M", "12M", with the effect being that the value always fits
> within a four-character field width, but this isn't a fixed number of
> decimal places *or* significan
On Wed, Aug 31, 2016, at 12:19, Guido van Rossum wrote:
> On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan wrote:
> > "h" would be a decent choice - it's not only a continuation of the
> > e/f/g pattern, it's also very commonly used as a command line flag for
> > "human-readable output" in system uti
On Aug 29 2016, Ken Kundert
wrote:
> Nikolaus,
> I have belatedly realized that this kind of hyperbole is counter
> productive.
> So let me back away from that statement and instead try to understand your
> reasons for not liking the proposal.
>
> Do you think there is no value to be able to
On 2016-08-31 17:19, Guido van Rossum wrote:
On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan wrote:
On 31 August 2016 at 17:07, Chris Angelico wrote:
On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
wrote:
> What's the mnemonic here? Why "r" for scale factor?
My thinking was that r stands for re
On 2016-08-31 05:08, Ken Kundert wrote:
What's the mnemonic here? Why "r" for scale factor?
My thinking was that r stands for real like f stands for float.
With the base 2 scale factors, b stands for binary.
'b' already means binary:
>>> '{:b}'.format(100)
'1100100'
On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan wrote:
> On 31 August 2016 at 17:07, Chris Angelico wrote:
>> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
>> wrote:
>>> > What's the mnemonic here? Why "r" for scale factor?
>>>
>>> My thinking was that r stands for real like f stands for float.
>>>
On Tue, Aug 30, 2016 at 5:48 AM, Ken Kundert
wrote:
> Erik,
> One aspect of astropy.units that differs significantly from what I am
> proposing is that with astropy.units a user would explicitly specify the scale
> factor along with the units, and that scale factor would not change even if
>
On 31 August 2016 at 17:07, Chris Angelico wrote:
> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
> wrote:
>> > What's the mnemonic here? Why "r" for scale factor?
>>
>> My thinking was that r stands for real like f stands for float.
>> With the base 2 scale factors, b stands for binary.
>
> "Real
On Tue, Aug 30, 2016 at 09:08:01PM -0700, Ken Kundert wrote:
> > What's the mnemonic here? Why "r" for scale factor?
>
> My thinking was that r stands for real like f stands for float.
Hmmm. Do you know many mathematicians who use SI prefixes when talking
about real numbers? I don't think "real
Thanks Chris.
I had misunderstood Steve's request, and I was thinking of something much more
complicated.
Your code is very helpful.
-Ken
On Wed, Aug 31, 2016 at 05:07:11PM +1000, Chris Angelico wrote:
> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
> wrote:
> > > What's the mnemonic here? Wh
On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
wrote:
> > What's the mnemonic here? Why "r" for scale factor?
>
> My thinking was that r stands for real like f stands for float.
> With the base 2 scale factors, b stands for binary.
"Real" has historically often been a synonym for "float", and it
do
On 31 August 2016 at 05:08, Ken Kundert wrote:
> Auto-scaling is kind of the point. There is really little need for a special
> mechanism if your going to specify the scale factor yourself.
>
> >>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, 50e3))
> Attenuation = -13.7 dB at 5
27 matches
Mail list logo
