On Tue, 13 Mar 2007, Phillip J. Eby wrote:
> Java, ironically, avoids this problem by forcing you to have new types for
> every single damn thing. The idiomatic way to have a priority-ordered
> sequence of socket event listeners is to make a new base class or interface
> just for that purpose
On 3/14/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
-- Forwarded message from python-3000-checkins --
Neal Norwitz schrieb:
> I assume this is not the desired behaviour?
>
class F:
> ... def __dir__(self):
> ... return [5]
> ...
dir(F())
> [5]
f = F()
d
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/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Patrick Maupin" <[EMAIL PROTECTED]> wrote:
> > Thanks for the feedback. For some reason, my post hasn't garnered
> > that much attention yet. Do I need to post it on python-dev or
> > c.l.p., or are people just really busy with other thi
(I've read the whole thread as it currently stands - responding to the
initial post to cover the various topics)
Patrick Maupin wrote:
> Feature: Alternate syntaxes for escape to markup.
> The syntaxes are similar enough that they can all be efficiently
> parsed by the same loop, so there are no
Neal Norwitz wrote:
> [Georg]
> This is modeled after the principle that for new-style objects, __special__
> methods are looked up on the type, not the instance.
>
> -
>
> 1) I didn't remember this, do we have it documented somewhere?
> 2) Assuming #1 is correct, is this rule consistently ap
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
Nick Coghlan wrote:
>> Feature: Exception raised if attribute with leading underscore accessed.
>>
>> The syntax supported by the PEP is deliberately limited in an attempt
>> to increase security. This is an additional security measure, which
>> is on by default, but can be optionally disabled if
-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
-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
Eric V. Smith wrote:
> Nick Coghlan wrote:
>>> Feature: Exception raised if attribute with leading underscore accessed.
>>>
>>> The syntax supported by the PEP is deliberately limited in an attempt
>>> to increase security. This is an additional security measure, which
>>> is on by default, but c
Eric V. Smith wrote:
> Nick Coghlan wrote:
>>> Feature: Exception raised if attribute with leading underscore accessed.
>>>
>>> The syntax supported by the PEP is deliberately limited in an attempt
>>> to increase security. This is an additional security measure, which
>>> is on by default, but c
On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > For uniformity and generality I propose to keep it. So the absolute
> > minimal signature for __prepare__ is actually:
> >
> > def __prepare__(name, bases, *, metaclass=None): ...
> >
> > this way the prepare functio
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'
On 3/14/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Including a very limited set of alternate syntaxes in the base
> formatting operation seems like a bad idea from a readability point of
> view.
The proposal includes the selection of (non-default) format options
via markup in the string itself
"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
At 08:49 PM 3/14/2007 +1300, Greg Ewing wrote:
>Talin wrote:
> > It does not need to implement the full dictionary interface;
> > only the ability to insert items and retrieve them are
> > required. (Note: double check that this is true).
>
>Deletion ability might be required as well
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
I think we're far enough along with the new I/O PEP and trial
implementation that I'm uncomfortable with the PEP living in Google
docs only (http://docs.google.com/Doc?id=dfksfvqd_1cn5g5m). Does
someone have half an hour of time available to convert it to standard
PEP mark-up? See PEP 9 or 12.
If
On 3/14/07, Talin <[EMAIL PROTECTED]> wrote:
> PEP: xxx
> Title: Metaclasses in Python 3000
Looks good.
> # The metaclass
> class OrderedClass(type):
>
> # The custom dictionary
> class member_table(dict):
> def __init__(self):
>self.member_
On Mon, Mar 12, 2007 at 05:30:48PM -0700, Guido van Rossum wrote:
> Executive summary: I'm defending the PEP and the metaclass syntax it
> proposes, and in fact I want the "clas arguments" to have the same
> syntax as a call, including *args and **kwds. I'm only suggesting to
> find a new name inst
On Wed, Mar 14, 2007 at 12:29:09AM -0700, Talin wrote:
> # The metaclass
> class OrderedClass(type):
>
> # The custom dictionary
> class member_table(dict):
I would move the member_table class out of the OrderedClass namespace so
no one gets any funny ideas that it ha
Jack Diederich <[EMAIL PROTECTED]> wrote:
[snip]
> I don't understand the keyword args other than 'metaclass.'
> If class D inherits from class C does it also get passed the 'Implements'
> keyword? If it does the same effect could be acheived by making a metaclass
> maker function and just using
On 3/14/07, Talin <[EMAIL PROTECTED]> wrote:
> PEP: xxx
> Title: Metaclasses in Python 3000
Checked in as PEP 3115. I fixed the two typos that were noted so far
(missing comma and inconsistency in name of first arg to __prepare__;
I renamed the latter metacls) and cleaned up one case of extra
whit
On 3/14/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > 1) I didn't remember this, do we have it documented somewhere?
> > 2) Assuming #1 is correct, is this rule consistently applied?
> > 3) How does (should) this affect 2.6 and migration to 3.0, if at all?
>
> The principle isn't consistently app
On 3/14/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 14/03/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> FWIW, I tend to agree with most of Josiah's responses. In particular,
> I'm afraid I hate the whitespace-sensitive alternative syntax. %...%
> syntax would be a reasonable alternative 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 3/14/07, Jack Diederich <[EMAIL PROTECTED]> wrote:
> I've snipped all the bits I understand and/or agree with.
I'm only quoting what I think needs clarification and/or hasn't
already been addressed. Note you're responding to an old thread; Talin
posted a new version of the PEP and I checked it
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
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
[Patrick Maupin]>
>So just to couch it all in terms of a proposal:
>
>- In 2.6 and 3.0, we add 0t1234 as a valid octal number
>- In 2.6, we issue a deprecation warning for a leading literal 0 which
>is followed immediately by another digit.
>- In 3.0, that becomes an exception
My suggestion:
- In
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
Guido van Rossum wrote:
> On 3/14/07, Talin <[EMAIL PROTECTED]> wrote:
>> PEP: xxx
>> Title: Metaclasses in Python 3000
>
> Checked in as PEP 3115. I fixed the two typos that were noted so far
> (missing comma and inconsistency in name of first arg to __prepare__;
> I renamed the latter metacls) a
On 3/14/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> - In 3.0, we don't want an exception. With floats and decimals, leading
> zeroes are allowed (i.e. 0.123). In 3.0, I would like the leading zero
> distinction to disappear from our collective memory. Somelike like
> eval('00987') s
At 11:15 AM 3/14/2007 -0700, Guido van Rossum wrote:
>I think this rebuttal isn't strong enough; I'm sure there *will* be
>use cases where a custom prepare method can solve a problem that a
>standard ordered dict couldn't.
For example, a custom prepare could provide access to special method names
> 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, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
- In 3.0, we don't want an exception.
Eh, no, you might not want one, but I most assuredly do want an exception.
Having formerly-octal literals suddenly give wrong results would be much
more of a stumbling block than having them in the
On 3/14/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 3/14/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > - In 3.0, we don't want an exception.
>
> Eh, no, you might not want one, but I most assuredly do want an exception.
> Having formerly-octal literals suddenly give wrong results
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
On 3/14/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
On 3/14/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 3/14/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > - In 3.0, we don't want an exception.
>
> Eh, no, you might not want one, but I most assuredly do want an
exception.
> Ha
>> - In 3.0, we don't want an exception. With floats and decimals,
>> leading zeroes are allowed (i.e. 0.123). In 3.0, I would like the
>> leading zero distinction to disappear from our collective memory.
>> Somelike like eval('00987') should give 987, not an exception.
>> The use cases fo
On 3/14/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On 3/14/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Sorry, but could you explain why having the -py3k flag raise the
> > exception for your 2.X code wouldn't be sufficient? Is it because you
> > expect your fingers will continue to type
I have a question about PEP 3001:
"""The last and most disruptive change is the overhaul of a module's
public interface. If a module's interface is to be changed, a
justification should be made beforehand, or a PEP should be written.
The change must be fully documented as "New in Version 3.0", an
> Leading zeroes are not a syntax error. Excel supports them for both input
> and output formats because accountants (like me) ocassionally need them.
> Schoolkids have an expectation that leading zeroes do not change the value.
> Your pocket calculator accepts leading zeroes. I do not suppor
>> I would like to additionally address the idea of "fixing" things
>> with a -py3k flag. Many (most) Python programmers will not migrate
>> all of their stuff to 3.0 overnight . . .
After hearing Guido's talk at PyCon, ISTM that Py3.0 will be accepted
widely and gracefully on its own merits. Ho
int('0012') should still return 12, no doubt about it, since the
default base is 10 and this is currently supported. Some business
users need to easily parse numbers output by Cobol. So should
int('0012', 10), which is really the same case. For int('0012', 0),
(the auto-base option) I'm not sure, a
Phillip J. Eby wrote:
> So the subset required is determined entirely by what the class body
> (and metaclass __new__) require.
Perhaps the PEP should say something to the effect that
get, set and delete need to be implemented in order to
support all the things the class body might want to do,
b
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? :
Raymond Hettinger wrote:
>>> I would like to additionally address the idea of "fixing" things
>>> with a -py3k flag. Many (most) Python programmers will not migrate
>>> all of their stuff to 3.0 overnight . . .
>
> After hearing Guido's talk at PyCon, ISTM that Py3.0 will be accepted
> widely an
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:
> We could even do this by hacking the default getattr
> implementation to skip the instance dict if the name starts and ends
> with two underscores.
But unless I'm mistaken, this behaviour is only
appropriate for *methods*, and you can't tell
just from whether the name has
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
Raymond Hettinger wrote:
> The use cases for
> zfill() correspond to the cases where leading zeros are meaningfully
> interpreted as decimals (this includes phone and social security numbers,
> account numbers, and whatnot).
They're NOT numbers! They're STRINGS!
Leading zeroes would only be dis
On 3/15/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> We could even do this by hacking the default getattr
> implementation to skip the instance dict if the name starts and ends
> with two underscores.
But unless I'm mistaken, this behaviour is only
appropriate for *method
While you're at it, could you also add a pointer to this patch as a
sample implementation?
http://python.org/sf/1681101
It's far from complete at this point; so far, I've got the syntax
working and it seems to compile old code just fine, but the keyword
args and */** notation are simply ignored.
[GvR]
>I agree with Thomas that allowing the literal 0012 in a program to
>return the value 10 would trip up old-timers too easily.
Did you mean "return the value 12 when 10 was intended"?
My worry focuses on new-timers and SyntaxErrors. The worst part of the new user
experience is encountering
On 3/14/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> >I agree with Thomas that allowing the literal 0012 in a program to
> >return the value 10 would trip up old-timers too easily.
>
> Did you mean "return the value 12 when 10 was intended"?
Yes, sorry.
> My worry focuses on new-tim
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
The PEP proposes that the class statement accepts keyword arguments,
*args, and **kwds syntax as well as positional bases. This is a bit
messy to compile and execute, but we already have this, of course, in
the code for calling regular functions.
So I think it would be acceptable to this into a ca
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
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:
> > 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
As Greg Ewing pointed out (tongue in cheek, I think, but I'm never
sure), it would be consistent with 'x' for hexadecimal and 't' for
octal to use 'n' for binary rather than 'b', e.g. theanswer = 0n101010
Part of me recoils at this, part of me agrees that this is not any
stranger than using 'x' fo
Guido van Rossum wrote:
> The PEP proposes that the class statement accepts
> keyword arguments, *args, and **kwds syntax as well
> as positional bases. This is a bit messy to compile
> and execute, but we already have this, of course, in
> the code for calling regular functions.
>
> So I think it
On 3/14/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > The PEP proposes that the class statement accepts
> > keyword arguments, *args, and **kwds syntax as well
> > as positional bases. This is a bit messy to compile
> > and execute, but we already have this, of cour
On 3/14/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think we're far enough along with the new I/O PEP and trial
> implementation that I'm uncomfortable with the PEP living in Google
> docs only (http://docs.google.com/Doc?id=dfksfvqd_1cn5g5m). Does
> someone have half an hour of time availa
Raymond Hettinger wrote:
> The worst part of the new user experience is encountering a
> SyntaxError. Because of the way we generate them, invalid
> syntax errors are not very informative
This seems like an argument for producing more informative
error messages. Something like
Syntax error
On 3/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Raymond Hettinger wrote:
>
> > The worst part of the new user experience is encountering a
> > SyntaxError. Because of the way we generate them, invalid
> > syntax errors are not very informative
>
> This seems like an argument for producing more
Let me restate that. It's obvious that a lot of error message have
had a lot of thought put into them, so when I said:
> so it would seem that
> nobody has turned a critical eye on the reporting of errors to nervous
> first-time programmers who are already worried they are going to break
> the ma
On Mar 14, 2007, at 6:26 PM, Guido van Rossum wrote:
> The PEP proposes that the class statement accepts keyword arguments,
> *args, and **kwds syntax as well as positional bases. This is a bit
> messy to compile and execute, but we already have this, of course, in
> the code for calling regular
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
Guido van Rossum wrote:
> So I think it would be acceptable to this into a call to a new
> (hidden) built-in function, named __build_class__.
>
>
> What do folks think?
Looks good to me. It'll also provide some interesting
new possibilities for overriding it in creative ways. :-)
--
Greg
__
72 matches
Mail list logo
