Those following the octal literal discussion might enjoy reading one of today's
SF bug reports:
www.python.org/sf/1715302
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 30, 2007, at 6:47 PM, Guido van Rossum wrote:
> The PEP editors have admitted to being behind on the job. AFAIK PEPs
> sent to the PEP editors before the deadline are in, regardless of when
> the PEP goes online.
>
> To save the PEP editors the
The PEP editors have admitted to being behind on the job. AFAIK PEPs
sent to the PEP editors before the deadline are in, regardless of when
the PEP goes online.
To save the PEP editors the effort, if you send it to me I will assign
it a PEP number and submit it. (Ditto for other PEPs in the same
s
I sent an email with an initial PEP to the PEP editors a few weeks
ago. Never got a reply. I noticed some traffic about this recently
but was too busy to follow it really carefully.
Pat
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > > implemented in pure python.
> >
> > I don't recall limitin
On 4/30/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > > implemented in pure python.
> >
> > I don't recall limitin
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Guido had set an Apr 30 deadline for Py3000 PEPs that can't be
> > implemented in pure python.
>
> I don't recall limiting the deadline in that way. Is this a general
> understanding?
FW
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I think these should be two separate proposals, with more specific
> > names (e.g. "remove implicit string concatenation" and "remove
> > backslash continuation"). There's no need to ment
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think these should be two separate proposals, with more specific
> names (e.g. "remove implicit string concatenation" and "remove
> backslash continuation"). There's no need to mention the octal thing
> if it's already a separate PEP.
Pat
I just want to mention that the issue, about removing octal literals,
has been discussed before:
http://www.python.org/dev/summary/2006-02-01_2006-02-15/#id10
-- Alexandre
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman
On 3/16/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 3/15/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> I have not seen any real
> requests for any bases other than 2, 8, 10, or 16.
What is the real need for 8?
Legacy protocols and such is my use case... and the benefit is not so much
"in
On 3/15/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> I have not seen any real
> requests for any bases other than 2, 8, 10, or 16.
What is the real need for 8?
The only use I've seen on the list is unix file permissions. Even if
that weren't obscure enough to stick in a module, I would still
On 3/15/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Please. No discussion of generalized radixes.
I agree. I was just stating the obvious that, if we allow 16r100,
somebody will ask why not 21r100.
>
> Also, IMO Tim's proposal changes too much; there's nothing wrong with 0b and
> 0x.
0b
On 3/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> What would you use for digits in bases higher
> than 36? Most of the ASCII punctuation is already
> taken... start plundering unicode for more
> alphabets?
I'm not suggesting that the number of supported bases should grow AT
ALL. What I am sugge
Patrick Maupin wrote:
> The max 36 radix currently supported by int() is
> numerically suspiciously similar to the sum of the number of ASCII
> digit characters and the number of same-case ASCII letters
What would you use for digits in bases higher
than 36? Most of the ASCII punctuation is already
Please. No discussion of generalized radixes.
Also, IMO Tim's proposal changes too much; there's nothing wrong with 0b and 0x.
On 3/15/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> On 3/15/07, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> > 2r1010
> > 4r22
> > 8r12
> > 16ra (or) 16r
On 3/15/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> 2r1010
> 4r22
> 8r12
> 16ra (or) 16rA
>
Part of me would miss 0xABCD terrbly, but I like the concept. The
only real rub is the impending huge discussion about the number of
allowed radices. The max 36 radix currently supported
[Guido]
> Something got lost there in a last-minute edit. I meant to say:
>
> My main interest is that we should move away from just leading zero as
> octal; that we should disallow leading zero altogether because of the
> confusion it would cause for folks coming from other languagesl and
> that w
Patrick Maupin wrote:
> Maybe I'm missing something. 2to3 needs to insert 't' after leading
> zeros for octal.
By "2to3" I meant the forthcoming 2-to-3 conversion tool.
--
Jeff Bauer
Rubicon, Inc.
___
Python-3000 mailing list
Python-3000@python.org
ht
On 3/14/07, Jeff Bauer <[EMAIL PROTECTED]> wrote:
> > 3) If this is a huge mistake, we can easily fix it before 2017.
>
> Agreed that it's easier to fix than something like
> integer division, but it would be nice to address
> in 2to3 (when there's already some understanding of
> backward incompati
Patrick Maupin wrote:
> 1) int('042') will keep evaluating to 42 (it does that right now)
Argh. Brain flatulence.
> 2) x = 042 will raise a SyntaxError
#2 is what I meant.
> 3) If this is a huge mistake, we can easily fix it before 2017.
Agreed that it's easier to fix than something like
inte
On 3/14/07, Jeff Bauer <[EMAIL PROTECTED]> wrote:
> I really didn't want to add to the traffic on this
> thread, but would like to keep leading zeros
> from raising a SyntaxError. If this passes, it
> will look as archaic in retrospect as the original
> decision to use '/' for integer division. A
I really didn't want to add to the traffic on this
thread, but would like to keep leading zeros
from raising a SyntaxError. If this passes, it
will look as archaic in retrospect as the original
decision to use '/' for integer division. And I'll
have to wait until 2017 for this to get rescinded in
Patrick Maupin wrote:
> how about:
>
> x = int("0x500")
I don't think that should be done by default. The
string passed to int often comes from user input,
and typical users aren't familiar with bases other
than 10, so it's more likely to be a typo if the
string contains non-digits.
Maybe th
Oleg Broytmann wrote:
> 0b101010
> 0c660
> 0xffe
>
>I.e. the first letter from "bin", the second from "oct", the third from
> "hex". Also "0c" resembles "oc" from "oct".
0c bothers me a bit, because it looks like it might
have something to do with characters.
What about 0k
Guido van Rossum wrote:
> How about 0t660?
> This is most symmetric with 0xffe for hex, as it is the 3rd letter of
> the word in both cases.
I like it.
> I think we also approved 0b101010 for binary numbers, didn't we?
Although for consistency with 0x an 0t it would
have to be 0n, wouldn't it? :
When you're done with the PEP, here's the code: http://python.org/sf/1681002
On 3/14/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
Sure. I'll do that tonight or tomorrow.
It would be great to get my feet wet on the process on a relatively
simple PEP. One other question, first though -- not t
> Can we wait until Unix file permissions are expressed in something
> other than octal?
The time machine at work:
machine:~/work/25 loewis$ ls -l x.py
-rw-r--r-- 1 loewis admin 22 Aug 25 2006 x.py
machine:~/work/25 loewis$ python
Python 2.3.5 (#1, Aug 19 2006, 21:31:42)
[GCC 4.0.1 (Apple
On 3/14/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> Sure. I'll do that tonight or tomorrow.
>
> It would be great to get my feet wet on the process on a relatively
> simple PEP. One other question, first though -- not that I want to
> open a huge can of worms or anything, but if we are trying
Sure. I'll do that tonight or tomorrow.
It would be great to get my feet wet on the process on a relatively
simple PEP. One other question, first though -- not that I want to
open a huge can of worms or anything, but if we are trying to make
things nice and consistent, how about:
x = int("0
Great! Mind writing up writing up a PEP that summarizes the discussion
(a bit)? In particular it should explain (a) why we need octal
literals; (b) why leading-zero is bad; (c) why we don't need general
bases; (d) why 0t is the best choice. Oh, and please add 0b too;
there's no formal proposal for
On 3/14/07, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>
> 0b101010
> 0c660
> 0xffe
>
>I.e. the first letter from "bin", the second from "oct", the third from
> "hex". Also "0c" resembles "oc" from "oct".
-1 on "c" It's too visually close to "0" in some fonts.
+1 on "t"
"t"
On Wed, Mar 14, 2007 at 06:59:03AM -0800, Guido van Rossum wrote:
> I really don't like to have to write int('660', 8). How about 0t660?
> This is most symmetric with 0xffe for hex, as it is the 3rd letter of
> the word in both cases.
>
> I think we also approved 0b101010 for binary numbers, didn
"Patrick Maupin" <[EMAIL PROTECTED]> writes:
>That's a great idea all the way around. Another possible syntax would
>be [EMAIL PROTECTED], [EMAIL PROTECTED], etc. I don't think that could mean
>anything
>currently.
It's a terrible idea all the way around. Be reasonable: in modern
code, only de
I would miss them too (again, as unix perms, which have a large swath
of my brain tissue devoted to them through nearly 30 years of use) but
I see the problem that Raymond mentioned (one of his colleagues fell
into the trap -- he didn't make this up)
I really don't like to have to write int('660'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 14, 2007, at 2:22 AM, Raymond Hettinger wrote:
> Nope. Just drop them from Python 3000. No one (except Greg) will
> miss them.
> The 2-to-3 tool can convert 0123 constants to decimal or hex. Any
> need to
> process external octal value c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 13, 2007, at 10:53 PM, Raymond Hettinger wrote:
> Now that the 20th century is safely behind us, do we still want
> literals with leading zeroes to be interpreted as octal?
Can we wait until Unix file permissions are expressed in something
Chris Rebert wrote:
> though a standard library function to convert arbitrary base
> representations of ints to ints might be useful.
>>> int('beef', 36)
531879
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
On 3/14/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Now that the 20th century is safely behind us, do we still want literals
with leading zeroes to be interpreted as octal?
What, this again? Without reading the rest of the thread I just know it'll
devolve into discussion about arbitrary-
On 14/03/2007 6.38, Greg Ewing wrote:
>> Do we deprecate it followed by a later removal (so as to "resist the
>> temptation to guess")? If so, sounds good to me (I've never had a use
>> for octal literals).
>
> I think that *some* syntax should be provided for octal
> literals.
If we get to t
On 14/03/2007 7.22, Raymond Hettinger wrote:
> [Josiah]
>> Do we deprecate it followed by a later removal
>
> Nope. Just drop them from Python 3000. No one (except Greg) will miss them.
> The 2-to-3 tool can convert 0123 constants to decimal or hex.
I don't think anyone use octal unless there
> Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Now that the 20th century is safely behind us, do we still want
>> literals with leading zeroes to be interpreted as octal?
[Josiah]
> Do we deprecate it followed by a later removal
Nope. Just drop them from Python 3000. No one (except Greg) wil
I agree that octal should still have a syntax. However, as you say, 0o
doesn't jump out as much typographically. And I'm wary of adding
arbitrary base literals to the language. It sounds like unnecessary
complexity, though a standard library function to convert arbitrary base
representations of
On 3/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 1101(2) # binary
> 1234(8) # octal
> 1c3a(16)# hexadecimal
> 12g7(35)# why stop at 16?
>
> Since calling a built-in integer never makes sense,
> this would be unambiguous.
That's a great idea all the way around. A
Josiah Carlson wrote:
> Do we deprecate it followed by a later removal (so as to "resist the
> temptation to guess")? If so, sounds good to me (I've never had a use
> for octal literals).
I think that *some* syntax should be provided for octal
literals. They're useful when you're translating co
Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Now that the 20th century is safely behind us, do we still want
> literals with leading zeroes to be interpreted as octal?
Do we deprecate it followed by a later removal (so as to "resist the
temptation to guess")? If so, sounds good to me (I've nev
Now that the 20th century is safely behind us, do we still want literals with
leading zeroes to be interpreted as octal?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http:
47 matches
Mail list logo
