On 2018-05-11 12:32:24 +0100, bartc wrote:
> I tried it in Python 3 (0o100.5 - I find that prefix fiddly to type actually
> as I have to stop and think), and it seems to be illegal.
You could also read the docs.
> Based floating point literals may be unusual, but bear in mind that in
> decimal,
On 12/05/2018 05:29, Steven D'Aprano wrote:
On Fri, 11 May 2018 16:56:09 +0100, bartc wrote:
0100, if not intended as octal, is
an undetectable error in C and Python 2.
How fortunate then that Python 2 is history (soon to be ancient history)
and people can use Python 3 where that error of jud
On Sat, May 12, 2018 at 6:44 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> Tack setuid onto "owner", setgid onto "group", and sticky
>> onto "others"? Pretty arbitrary, and disrupts the fundamental meaning
>> of each set.
>
>
> Yes, it would be totally silly if e.g. the "ls" command were
Marko Rauhamaa wrote:
I'm
guessing using letters as digits felt awkward among computer people for
a long time.
I think you may be underestimating how much weirdness
early computer programmers were willing to accept.
If you think using letters as hex digits is awkward,
you should check out what
Chris Angelico wrote:
Tack setuid onto "owner", setgid onto "group", and sticky
onto "others"? Pretty arbitrary, and disrupts the fundamental meaning
of each set.
Yes, it would be totally silly if e.g. the "ls" command were
to regroup them that way when displaying the permission bits...
oh, wai
Steven D'Aprano wrote:
You had
computers with 6, 9, or even 60 bits per byte,
And some early machines were even weirder, e.g. the EDSAC
with effectively 17-bit words and 35-bit longwords.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, 11 May 2018 16:56:09 +0100, bartc wrote:
> 0100, if not intended as octal, is
> an undetectable error in C and Python 2.
How fortunate then that Python 2 is history (soon to be ancient history)
and people can use Python 3 where that error of judgement has been
rectified.
--
Steve
-
>
> And, if it is really necessary to retain
> octal, why not preface it with anything BUT a "0".
>
I believe "0o" offers some symmetry with the "0x" prefix used for hex
literals. (And "0b" for binary.) It's a bit unfortunate that zero and
capital "oh" are visually so similar. Not much to be done
On Fri, May 11, 2018 at 10:35 AM, Ian Kelly wrote:
> On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano
> wrote:
>> On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:
>>
>>> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
>>> wrote:
On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote abou
On Fri, May 11, 2018 at 12:19 AM, Steven D'Aprano
wrote:
> On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:
>
>> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
>> wrote:
>>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>>> prefixes for octal:
>>>
Personally I woul
On 11/05/2018 14:24, Chris Angelico wrote:
On Fri, May 11, 2018 at 9:09 PM, bartc wrote:
when 101'11010'000'B then ...
Try /that/ in hex /or/ octal.)
I've no idea what this is supposed to mean, or why you have groups of
three, five, and three. Looks like a possible bug to me. I'm sure
On 2018-05-11, Grant Edwards wrote:
> On 2018-05-11, Gene Heskett wrote:
>> Computers haven't read a single 8 bit byte in years, some reading
>> 128 or 256 bits in a single read cycle today.
>
> Nonsense. All modern CPUs that I'm aware of still still support
> single byte reads, and compilers st
On 2018-05-11, Steven D'Aprano wrote:
> On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote:
>
>> Hex came into vogue in the DEC world with the VAX, which was both
>> byte-addressed and had a hex-oriented instruction encoding.
>
>
> [...] You had computers with 6, 9, or even 60 bits per byte
On 2018-05-11, Dennis Lee Bieber wrote:
> On Fri, 11 May 2018 01:55:58 +0100, bartc declaimed the
> following:
>
>>On 11/05/2018 01:25, Marko Rauhamaa wrote:
>>> Chris Angelico :
>>>
Octal makes a lot of sense in the right contexts.
>>>
>>> I think octal is a historical relic from a time w
On 2018-05-11, Gene Heskett wrote:
> Computers haven't read a single 8 bit byte in years, some reading
> 128 or 256 bits in a single read cycle today.
Nonsense. All modern CPUs that I'm aware of still still support
single byte reads, and compilers still use those instructions when the
size of t
Chris Angelico :
> On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing
> wrote:
>> I think the idea is that you could regroup those 4 groups of 3 into 3
>> groups of 4, and get a nice mapping to hex. If hex had been the
>> conventional way of writing binary numbers back then, Ken and Dennis
>> would p
On Fri, May 11, 2018 at 9:09 PM, bartc wrote:
> On 11/05/2018 01:11, Chris Angelico wrote:
>>
>> On Fri, May 11, 2018 at 8:43 AM, bartc wrote:
>>>
>>> This is Wrong, and would have been just as obviously wrong in 1989.
>>
>>
>> Having spent many years programming in C and working on Unix, I
>> st
On Fri, May 11, 2018 at 8:08 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> What do you mean, "another bit"? Currently, the chmod command on my
>> system can manage nine primary bits (rwx for each of ugo), plus
>> setuid, setgid, and sticky.
>
>
> I think the idea is that you could regroup
Ben Bacarisse :
> bartc writes:
>> On 11/05/2018 01:25, Marko Rauhamaa wrote:
>>> I think octal is a historical relic from a time when people weren't
>>> yet comfortable with hexadecimal.
>>
>> It's a relic from when machines had word sizes that were multiples of
>> three bits, or were divided up
bartc writes:
> On 11/05/2018 01:25, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> Octal makes a lot of sense in the right contexts.
>>
>> I think octal is a historical relic from a time when people weren't yet
>> comfortable with hexadecimal.
>
> It's a relic from when machines had word sizes
On 10/05/2018 21:18, bartc wrote:
On 10/05/2018 19:51, Chris Angelico wrote:
On Fri, May 11, 2018 at 4:31 AM, bartc wrote:
2x100 (4) Binary
3x100 (9) Ternary
4x100 (16) Quaternary
5x100 (25) etc
6x100 (36)
7x100 (49)
8x100 (64) Octal
9x100 (81)
...
On 11/05/2018 01:11, Chris Angelico wrote:
On Fri, May 11, 2018 at 8:43 AM, bartc wrote:
This is Wrong, and would have been just as obviously wrong in 1989.
Having spent many years programming in C and working on Unix, I
strongly disagree.
Using C is apt to give you a rather warped view of
On Fri, 11 May 2018 21:55:17 +1200, Gregory Ewing wrote:
> Hex came into vogue in the DEC world with the VAX, which was both
> byte-addressed and had a hex-oriented instruction encoding.
Indeed. In 2018 when nearly all computers (aside from some DSPs) have
standardised on the same number of bit
On 2018-05-10, Chris Angelico wrote:
> On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens
> wrote:
>> This whole thread is reminding me PHP 2, which would magically treat
>> the second parameter of ChMod() as octal, because clearly if weak
>> typing is good then *no* typing must be best of all!
>>
>>
Steven D'Aprano wrote:
n for binary
t for octal
i for trinary
o for duodecimal
and of course, x for hexadecimal.
And in format strings:
"c" for decimal
"a" for char
"r" for string
"w" for raw string
Looks fine to me. Who wants to write the PEP?
--
Greg
--
https://mail.python.org/mai
Chris Angelico wrote:
What do you mean, "another bit"? Currently, the chmod command on my
system can manage nine primary bits (rwx for each of ugo), plus
setuid, setgid, and sticky.
I think the idea is that you could regroup those 4 groups
of 3 into 3 groups of 4, and get a nice mapping to hex.
Marko Rauhamaa wrote:
I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.
Octal made perfect sense for all PDP models up to the
PDP-10, which had word sizes that were a multiple of
3 bits.
It still partly made sense for the PDP-11, because its
Chris Angelico wrote:
Octal makes a lot of sense in the right contexts. Allowing octal
literals is a Good Thing. And sticking letters into the middle of a
number doesn't make that much sense, so the leading-zero notation is a
decent choice.
Also it's easy to forget that octal was a big part of
On 10/05/2018 19:51, Chris Angelico wrote:
YAGNI much? How often do you need a base-9 literal in your code??
You've obviously never programmed a Setun ternary computer:
https://en.wikipedia.org/wiki/Setun
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, May 11, 2018 at 12:04 PM, Bob van der Poel wrote:
> I agree with my freind Gene! And, if it is really necessary to retain
> octal, why not preface it with anything BUT a "0". I've been hit by this a
> few times in the past. I used lots of hex over the years, but don't recall
> ever using o
On Thu, 10 May 2018 23:23:33 -0600, Ian Kelly wrote:
> On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
> wrote:
>> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>> prefixes for octal:
>>
>>> Personally I would have preferred the "t".
>>
>> "t" for octal, hey?
>>
>> That woul
On Thursday 10 May 2018 23:21:11 Steven D'Aprano wrote:
> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
>
> prefixes for octal:
> > Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
>
On Thu, May 10, 2018 at 9:21 PM, Steven D'Aprano
wrote:
> On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
> prefixes for octal:
>
>> Personally I would have preferred the "t".
>
> "t" for octal, hey?
>
> That would be annoying if we ever get trinary literals.
>
> n for binary
>
On Thu, 10 May 2018 11:03:54 -0600, Ian Kelly wrote about proposed
prefixes for octal:
> Personally I would have preferred the "t".
"t" for octal, hey?
That would be annoying if we ever get trinary literals.
n for binary
t for octal
i for trinary
or should that be r for ternary?
o for duodecim
On Thu, 10 May 2018 17:36:39 +0100, bartc wrote:
> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.
Because in 1991 or thereabouts, when Guido was designing the language for
the first time, he thought it wa
On Thu, May 10, 2018 at 6:36 PM, Gene Heskett wrote:
> On Thursday 10 May 2018 20:55:58 bartc wrote:
>
> > On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > > Chris Angelico :
> > >> Octal makes a lot of sense in the right contexts.
> > >
> > > I think octal is a historical relic from a time when pe
On Fri, May 11, 2018 at 11:36 AM, Gene Heskett wrote:
> So other than the *nix chmod, and some similar stuff in
> os9/nitros9/amigados, I have never had to deal with octal. I'm sure the
> security people would be pleased if another bit could be expanded into
> the permissions that chmod controls,
On Thursday 10 May 2018 20:55:58 bartc wrote:
> On 11/05/2018 01:25, Marko Rauhamaa wrote:
> > Chris Angelico :
> >> Octal makes a lot of sense in the right contexts.
> >
> > I think octal is a historical relic from a time when people weren't
> > yet comfortable with hexadecimal.
>
> It's a relic
On Fri, May 11, 2018 at 10:25 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Octal makes a lot of sense in the right contexts.
>
> I think octal is a historical relic from a time when people weren't yet
> comfortable with hexadecimal.
And any other situation where it makes more sense to group
On 11/05/2018 01:25, Marko Rauhamaa wrote:
Chris Angelico :
Octal makes a lot of sense in the right contexts.
I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.
It's a relic from when machines had word sizes that were multiples of
three bi
Chris Angelico :
> Octal makes a lot of sense in the right contexts.
I think octal is a historical relic from a time when people weren't yet
comfortable with hexadecimal.
> Allowing octal literals is a Good Thing.
I think it's just unavoidable mainly because of os.chmod.
Marko
--
https://mai
On Fri, May 11, 2018 at 8:43 AM, bartc wrote:
> This is Wrong, and would have been just as obviously wrong in 1989.
Having spent many years programming in C and working on Unix, I
strongly disagree. This was *not* obviously wrong. It's easy to say
"but look at the real world"; but in the 80s and
On 10/05/2018 18:58, Skip Montanaro wrote:
I wonder why someone would take a feature generally agreed to be a
poorly designed feature of C, and incorporate it into a new language.
I think you might be looking at a decision made in the late 1980s through a
pair of glasses made in 2018.
As a C p
On 10/05/2018 19:51, Chris Angelico wrote:
On Fri, May 11, 2018 at 4:31 AM, bartc wrote:
2x100 (4) Binary
3x100 (9) Ternary
4x100 (16) Quaternary
5x100 (25) etc
6x100 (36)
7x100 (49)
8x100 (64) Octal
9x100 (81)
... (Not implemented 11x to 15x,
> Bear in mind that Unix file modes are traditionally written in octal,
> because they have no meaning as numbers. They're more like
> enumerations, or bitfields.
The current chmod(2) man page says that the type of the second is mode_t,
but back in the early days, it appears it was just declared t
On 2018-05-10, Jon Ribbens wrote:
> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>
> ChMod($filename, 644); // second parameter is actually 420 base
> This whole thread is reminding me PHP 2, which would magically treat
> the second parameter of ChMod() as octal, because clearly if weak
> typing is good then *no* typing must be best of all!
>ChMod($filename, 644); // second parameter is actually 420 base 10
I knew there was a reason I nev
On Fri, May 11, 2018 at 5:04 AM, Jon Ribbens wrote:
> On 2018-05-10, Skip Montanaro wrote:
>>> I wonder why someone would take a feature generally agreed to be a
>>> poorly designed feature of C, and incorporate it into a new language.
>>
>> I think you might be looking at a decision made in the
On 2018-05-10, Skip Montanaro wrote:
>> I wonder why someone would take a feature generally agreed to be a
>> poorly designed feature of C, and incorporate it into a new language.
>
> I think you might be looking at a decision made in the late 1980s through a
> pair of glasses made in 2018.
>
> As
On Fri, May 11, 2018 at 4:31 AM, bartc wrote:
> 2x100 (4) Binary
> 3x100 (9) Ternary
> 4x100 (16) Quaternary
> 5x100 (25) etc
> 6x100 (36)
> 7x100 (49)
> 8x100 (64) Octal
> 9x100 (81)
> ... (Not implemented 11x to 15x, nor 10x or 16x)
> 0x100 (256) Hex
On 10/05/2018 18:03, Ian Kelly wrote:
On Thu, May 10, 2018 at 10:36 AM, bartc wrote:
What, 0O100 instead of 0100? Yeah that's a big improvement...
Fortunately octal doesn't get used much.
The PEP discusses this:
"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16
> I wonder why someone would take a feature generally agreed to be a
> poorly designed feature of C, and incorporate it into a new language.
I think you might be looking at a decision made in the late 1980s through a
pair of glasses made in 2018.
As a C programmer back then I never had a problem
On 2018-05-10 18:03, Ian Kelly wrote:
On Thu, May 10, 2018 at 10:36 AM, bartc wrote:
What, 0O100 instead of 0100? Yeah that's a big improvement...
Fortunately octal doesn't get used much.
The PEP discusses this:
"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16
On Thu, May 10, 2018 at 10:36 AM, bartc wrote:
> What, 0O100 instead of 0100? Yeah that's a big improvement...
>
> Fortunately octal doesn't get used much.
The PEP discusses this:
"""
Proposed syntaxes included things like arbitrary radix prefixes, such
as 16r100 (256 in hexadecimal), and radix
On Thu, May 10, 2018 at 5:49 AM, D'Arcy Cain wrote:
> On 2018-05-10 07:28 AM, Skip Montanaro wrote:
>> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
>
> Funny stuff:
>
> Python could either:
>
> 1. silently do the wrong thing...
> 2. immediately disabuse him...
>
On 10/05/2018 12:28, Skip Montanaro wrote:
This gave the following error:
Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
d0 = date(2018,02,01)
Note that this is a Python syntax error. It actually has nothing to do w
On 2018-05-10 13:52, D'Arcy Cain wrote:
On 2018-05-10 07:39 AM, AK wrote:
Try (should work from both PY2 and PY3):
d0 = date(2018,0o2,0o1)
Bad advice. Those numbers are decimal, not octal, You should use
"date(2018,2,1)" here. Works in PY2, PY3 and for my birthday, Sept 4.
It was only an
On 2018-05-10 07:28 AM, Skip Montanaro wrote:
> https://www.python.org/dev/peps/pep-3127/#removal-of-old-octal-syntax
Funny stuff:
Python could either:
1. silently do the wrong thing...
2. immediately disabuse him...
3. let him continue to think...
Some people passionately believe t
On 2018-05-10 07:39 AM, AK wrote:
> Try (should work from both PY2 and PY3):
>
> d0 = date(2018,0o2,0o1)
Bad advice. Those numbers are decimal, not octal, You should use
"date(2018,2,1)" here. Works in PY2, PY3 and for my birthday, Sept 4.
--
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.Vy
On 2018-05-10 12:43, Virgil Stokes wrote:
Module info:
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64
bit (AMD64)]
[...]
I tried first to use Python's built-in datetime module as follows:
from datetime import date, timedelta
d0 = date(2018,02,01)
This gave the fol
On Thu, 10 May 2018 12:43:33 +0200, Virgil Stokes wrote:
> Why does the datetime.date module (both built-in and site-package) not
> accept leading 0's?
This has nothing to do with the datetime module. Syntax Error means it it
prohibited by the language, not the module.
In Python 2, leading ze
>
> This gave the following error:
>
> Syntax Error: invalid token: C:\Users\Virgil Stokes\Desktop\Important
> Notes_Files\CheckProcessingDate_02.py, line 7, pos 17
> d0 = date(2018,02,01)
>
Note that this is a Python syntax error. It actually has nothing to do with
the datetime module. In Python
Module info:
Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64
bit (AMD64)]
C:\Python36>pip show datetime
Name: DateTime
Version: 4.2
Summary: This package provides a DateTime data type, as known from Zope
2. Unless you need to communicate with Zope 2 APIs, you're probabl
63 matches
Mail list logo
