> So, Martin, I suggest that you expand your proposal to include a
> transliteration mechanism and limit the allowed characters to those which
> can be translitered. I presume that this would be an expanding set. Once
> a mechanism is in place, people who want 'their' character set included ca
> He says "the tools aren't ready yet", which I take to
> mean that Python won't need to support it until all
> widely-used editors, email and news software, etc, etc,
> reliably support displaying and editing of all
> unicode characters. We're clearly a long way from
> that situation.
I don't und
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On 01/05/2007 12.52, Martin v. Löwis wrote:
| Isn't this already blacklisted in PEP 3099?
In today's Pep Parade post, he implies no.
"PEP: Supporting Non-ASCII identifiers (Martin von Loewis)
I'm on record as not liki
Leonardo Santagada wrote:
> but all of the literals on the sintax of python would be better if
> they can be on the programmers language, as what the guys from OLPC
> want.
It's not clear to me that that's what we want, actually. I think Alan
Kay mentioned that they can do this level of i18n
I don't know if I can speak on the py3k list, but I would give this a
-1.
Supporting non-ascii identifiers don't fix the bigger problem. People
want to write programs in their own language. Not only identifiers,
but all of the literals on the sintax of python would be better if
they can b
On Tuesday 01 May 2007, Jason Orendorff wrote:
> Come to think of it, Inform 7 is the other system I know of that has
> an advice system like this. Now I'm suspicious. Are you trying to
> turn Python into some kind of game?
Software is always a game, and I've been beginning to think the spoil
Thanks for writing this!
At 08:10 PM 5/1/2007 -0700, Talin wrote:
>Other kinds of transformations would include:
Compilation is a collection of such transforms over an AST, by the
way. Documentation generators are transforms over either an AST
(source-based doc generators) or a set of modules'
At 02:50 PM 5/2/2007 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
> > The PEP lists *five* built-in decorators, all of which support this
> behavior::
> >
> > @overload, @when, @before, @after, @around
>
>This seems massively over-designed. All you need is the
>ability to call the next meth
At 10:43 PM 5/1/2007 -0400, Jason Orendorff wrote:
>In short, you have to ask
>yourself: am I hooking something (before/after), implementing it
>(when), or just generally looking for trouble (around)?
Nice summary! I'll add something like this to the PEP, although I suppose
I'll have to make the
At 07:37 PM 5/1/2007 -0700, Guido van Rossum wrote:
>On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > However, since your objections are more in the nature of general unease
> > than arguments against, it probably doesn't make sense for me to continue
> > quibbling with them point by point,
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> Thus, when someone is offered something, they may say, "I'll pass",
| > meaning they are declining to act. Ergo, to "pass" in Python is to
| > decline to give up the opportunity to act.
The person being quoted m
Guido was complaining to me today, something along the lines that every
time someone presents him with an example of Haskell code, his eyes
start glazing over. I have pretty much the same problem, even though
I've actually taken the time to read a little bit about Haskell.
If you are someone wh
On 5/1/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Daniel Stutzbach" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | Sort O(n log n) O(n log n)
>
> Tim Peters' list.sort is, I believe, better than nlogn for a number of
> practically important speci
One of my concerns in the ABC/interface discussion so far is that a lot
of the use cases presented are "toy" examples. This makes perfect sense
considering that you don't want to have to spend several pages
explaining the use case. But at the same time, it means that we might be
solving problem
Phillip J. Eby wrote:
> The PEP lists *five* built-in decorators, all of which support this behavior::
>
> @overload, @when, @before, @after, @around
This seems massively over-designed. All you need is the
ability to call the next method, and you can get all of
these behaviours. If you call i
Guido van Rossum wrote:
> S 3125 Remove Backslash ContinuationJewett
>
> Sounds reasonable. I think we should still support \ inside string
> literals though; the PEP isn't clear on this. I hope this falls within
> the scope of the refactoring tool (sandbox/2to3).
I'm a strong
At 07:21 PM 5/1/2007 -0700, Talin wrote:
>Well, I suppose you could make "chained" a modifier of the decorator, so
>for example @operator.chained, @discount.chained, and so on. In other
>words, the decorator can be called directly, or the attribute 'chained'
>also produces a callable that causes th
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:22 PM 5/1/2007 -0400, Jason Orendorff wrote:
> >I think I would prefer to *always* pass the next method
> >to @around methods, which always need it, and *never*
> >pass it to any of the others. What use case am I missing?
>
> Calling the
Martin v. Löwis wrote:
> I still don't understand why the "no operation" statement is called
> "pass" - it's not the opposite of "fail", and seems to have no
> relationship to "can you pass me the butter, please?".
It's "pass" as in "pass through", i.e. move on to the next
statement without stopp
On 5/1/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Also, what should this do? Perhaps the grammar could disallow it?
> >
> > *a = range(5)
>
> I say disallow it. That is ambiguous as to what your intentions are even if
> you know what '*' does for multiple assignment.
My real point was that t
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> However, since your objections are more in the nature of general unease
> than arguments against, it probably doesn't make sense for me to continue
> quibbling with them point by point, and instead focus on how to move forward.
Thanks for indu
Martin v. Löwis wrote:
> http://mail.python.org/pipermail/python-3000/2006-April/001526.html
>
> where Guido states that he trusts me that it can be made to work,
> and that "eventually" it needs to be supported.
He says "the tools aren't ready yet", which I take to
mean that Python won't need t
Phillip J. Eby wrote:
> At 09:13 AM 5/1/2007 -0700, Talin wrote:
>> Phillip J. Eby wrote:
>>> Proceeding to the "Next" Method
>>> ~~~
>>> If the first parameter of an overloaded function is named
>>> ``__proceed__``, it will be passed a callable representing the next
>>>
On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 5/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> This is a bit late, but it was in my queue by April 30, I swear! ;)
Accepted.
> Comments are appreciated, especially some phrasing sounds very clumsy
> to me, but I couldn't find a bette
In the interest of furthering the discussion, here are two past
threads on similar suggestions:
[Python-Dev] Half-baked proposal: * (and **?) in assignments
http://mail.python.org/pipermail/python-dev/2002-November/030349.html
[Python-ideas] Javascript Destructuring Assignment
http://mail.python.
At 05:52 PM 5/1/2007 -0700, Guido van Rossum wrote:
>I rather like the idea that it warns readers who are new to GFs and more
>familiar with how functions behave in Python 2.
Until somebody adds an overload, it *does* behave the same; that was sort
of the point. :)
>Also noting that __code__ i
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:04 PM 5/1/2007 -0700, Guido van Rossum wrote:
> >On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
> > > >Suppose you couldn't assign to __class__ of a function (that's too
> >
"Daniel Stutzbach" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Sort O(n log n) O(n log n)
Tim Peters' list.sort is, I believe, better than nlogn for a number of
practically important special cases. I believe he documented this in the
code comme
Neville Grech Neville Grech wrote:
> This reminds me a lot of haskell/prolog's head/tail list splitting. Looks
> like a good feature.
Agreed!
> a*=range(5)
> hmmn maybe in such a case, whenever there is the * operator, the resulting
> item is always a list/tuple, like the following:
> a=[[0,1,2,3,
At 02:04 PM 5/1/2007 -0700, Guido van Rossum wrote:
>On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
> > >Suppose you couldn't assign to __class__ of a function (that's too
> > >messy to deal with in CPython) and you couldn't assign to it
This reminds me a lot of haskell/prolog's head/tail list splitting. Looks
like a good feature.
a*=range(5)
hmmn maybe in such a case, whenever there is the * operator, the resulting
item is always a list/tuple, like the following:
a=[[0,1,2,3,4]] ?
I have another question, what would happen in t
On 5/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> This is a bit late, but it was in my queue by April 30, I swear! ;)
Accepted.
> Comments are appreciated, especially some phrasing sounds very clumsy
> to me, but I couldn't find a better one.
>
> Georg
>
>
> PEP: 3132
> Title: Extended Iterabl
This is a bit late, but it was in my queue by April 30, I swear! ;)
Comments are appreciated, especially some phrasing sounds very clumsy
to me, but I couldn't find a better one.
Georg
PEP: 3132
Title: Extended Iterable Unpacking
Version: $Revision$
Last-Modified: $Date$
Author: Georg Brandl <[E
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
> >Suppose you couldn't assign to __class__ of a function (that's too
> >messy to deal with in CPython) and you couldn't assign to its __code__
> >either. What proposed functionality would you
On 1 May 2007, at 20:14, Jason Garber wrote:
> In PEP 249 (Python Database API Specification v2.0), there is a
> paragraph about cursors that reads:
>
> .execute(operation[,parameters])
>Prepare and execute a database operation (query or
>command). Parameters may be provided as sequence or
From: "Jim Jewett" <[EMAIL PROTECTED]>
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>> So the PEP submissions are in, and a few late ones will be submitted
>> ASAP. Let me write up a capsule review of what we've got. Please let
>> me know if I missed anything (e.g. a PEP that someon
For what is worth changing func_code is supported both by PyPy and
Jython. What cannot be done
in Jython is construct a code object out of a string of CPython
bytecode, but it can be extracted from
other functions.
Jython 2.2b1 on java1.5.0_07
Type "copyright", "credits" or "license" for more in
Martin v. Löwis schrieb:
>> Reading from
>> http://mail.python.org/pipermail/python-3000/2006-April/001474.html,
>> the message that prompted this particular addition to PEP 3099, "I
>> want good Unicode support for string literals and comments. Everything
>> else in the language ought to be ASCII.
Hello,
In PEP 249 (Python Database API Specification v2.0), there is a
paragraph about cursors that reads:
.execute(operation[,parameters])
Prepare and execute a database operation (query or
command). Parameters may be provided as sequence or
mapping and will be bound to variables in t
At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
>Suppose you couldn't assign to __class__ of a function (that's too
>messy to deal with in CPython) and you couldn't assign to its __code__
>either. What proposed functionality would you lose?
The ability to overload any function, without having
Suppose you couldn't assign to __class__ of a function (that's too
messy to deal with in CPython) and you couldn't assign to its __code__
either. What proposed functionality would you lose? How would you
ideally implement that functionality if you had the ability to modify
CPython in other ways? (I
On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> > > There are some things you can safely do with even arbitrary objects --
> > > such as appending them to a list.
>
> > > By mentioning
On 5/1/07, Patrick Maupin <[EMAIL PROTECTED]> wrote:
> attributes with leading underscores. This makes it relatively easy to
> write "format-safe" objects. Does it make it impossible to write a
> "format-unsafe" object? No, and that was never the intention.
Agreed; I just think this restrictio
At 11:31 AM 5/1/2007 -0700, Guido van Rossum wrote:
>I haven't had the time to read this in detail, but in general I'm
>feeling favorable about this idea. I'd rather see it decoupled from
>sys._getframe() and modifying func_code (actually __code__ nowadays,
>see PEP 3100).
I've figured out how to
On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > So the PEP submissions are in, and a few late ones will be submitted
> > ASAP. Let me write up a capsule review of what we've got. Please let
> > me know if I missed anything (e.g. a PEP
On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So the PEP submissions are in, and a few late ones will be submitted
> ASAP. Let me write up a capsule review of what we've got. Please let
> me know if I missed anything (e.g. a PEP that someone has committed to
> write but hasn't submitted
Jim Jewett wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
>>> There are some things you can safely do with even arbitrary objects --
>>> such as appending them to a list.
>
>>> By mentioning security as a reason to restrict th
On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > But your presumption that the map is already evil makes it irrelevant
> > whether the format is safe or not. Having the evil map is the problem,
> > not passing it to the format operation.
At 02:13 PM 5/1/2007 -0400, Jim Jewett wrote:
>On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Yup, and we're still not now. :) Or at least, I don't understand what the
> > code below does, or more precisely, why it's different from just having a
> > __decorators__ list containing direct
At 02:22 PM 5/1/2007 -0400, Jason Orendorff wrote:
>On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 09:13 AM 5/1/2007 -0700, Talin wrote:
>> >I don't care for the idea of testing against a specially named argument.
>> >Why couldn't you just have a different decorator, such as
>> >"overloa
On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > There are some things you can safely do with even arbitrary objects --
> > such as appending them to a list.
> > By mentioning security as a reason to restrict the format, it suggests
> >
On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> PEP: Adding class decorators (???)
>
> I'm in favor of this. I'm just writing for someone to write it up.
I just checked in PEP 3129, "Class Decorators".
Collin Winter
___
Python-3000 mailing list
So the PEP submissions are in, and a few late ones will be submitted
ASAP. Let me write up a capsule review of what we've got. Please let
me know if I missed anything (e.g. a PEP that someone has committed to
write but hasn't submitted yet).
First the PEPs that have numbers as of this writing (I'
On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> > > Note that while (literal strings used as) format strings are
> > > effectively sandboxed, the formatted objects themselves are not.
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:13 AM 5/1/2007 -0700, Talin wrote:
> >I don't care for the idea of testing against a specially named argument.
> >Why couldn't you just have a different decorator, such as
> >"overload_chained" which triggers this behavior?
>
> The PEP li
On 5/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Note that while (literal strings used as) format strings are
> > effectively sandboxed, the formatted objects themselves are not.
> > "My name is {0[name]}".format(evil_map)
> > woul
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:11 AM 5/1/2007 -0400, Jim Jewett wrote:
> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >> >>PEP 3115, however, requires that a class' metaclass be determined
> >> >>
Robert Brewer schrieb:
> Martin v. Löwis wrote:
>> Subject: [Python-3000] PEP: Supporting Non-ASCII Identifiers
>>
>> Common Objections =
>>
>> People claim that they will not be able to use a library if to do
>> so they have to use characters they cannot type on their keyboards.
On May 1, 2007, at 12:19 PM, Jim Jewett wrote:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> The identifier syntax is \*.
>
>> ID_Start is defined as all characters having one of the general
>> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
>> letters (Lt),
I don't like this -- it seems like rewriting history to me. I'd rather
leave PEP 318 alone and create a new PEP. Of course the new PEP can be
short because it can refer to PEP 318.
--Guido
On 5/1/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> In talking to Neal Norwitz about this, I don't see a n
There seems to be an issue with the PEP index:
http://python.org/dev/peps/ lists PEP 3122 as the last PEP (not
counting PEP 3141 which is deliberately out of sequence). As a
work-around, an up to date index is here:
http://python.org/dev/peps/pep-/
PEPs 3123-3128 are alive and well and reac
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I just wanted to throw in a note for those who are upset with the idea that
> classes should be able to decide how isinstance() and issubclass()
> work. If you want "true, unforgeable" isinstance and subclass, you can
> still use these formula
Martin v. Löwis wrote:
> Subject: [Python-3000] PEP: Supporting Non-ASCII Identifiers
>
> Common Objections
> =
>
> People claim that they will not be able to use a library if to do so
> they have to use characters they cannot type on their
> keyboards. However, it is the choice o
On 5/1/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> PEP: 30XX
> Title: BList: A faster list-like type
Checked in as PEP 3128.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http
Alan McIntyre writes:
> I have a nagging concern that these additions will
> clutter up the core, and--no matter how hard you try--adding them is
> going to have an impact on "run-of-the-mill" users of the language.
I don't think that will be the case, if we just use ABCs. There will
be a definit
> Thus, when someone is offered something, they may say, "I'll pass",
> meaning they are declining to act. Ergo, to "pass" in Python is to
> decline to give up the opportunity to act.
Ah, ok. It would then be similar to "Passe!" in German, which is
used in card games, if you don't play a card, bu
Greg Ewing writes:
> But I don't think there is any such definition, and
> the confusion arises because people lazily use the
> vague term "file-like" instead of spelling out what
> they really mean ("has a read() method", etc.)
Yes, I agree with this. That's why
http://wiki.python.org/moin/Abstr
On 5/1/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 4/30/07, Talin <[EMAIL PROTECTED]> wrote:
> > Greg Ewing wrote:
> > > Patrick Maupin wrote:
>
> > >> Method calls are deliberately disallowed by the PEP, so that the
> > >> implementation has some hope of being securable.
>
> > > If attribute ac
At 06:14 PM 5/1/2007 +0200, Martin v. Löwis wrote:
>I still don't understand why the "no operation" statement is called
>"pass" - it's not the opposite of "fail", and seems to have no
>relationship to "can you pass me the butter, please?".
Actually, it does, in the sense that to "pass" on somethi
At 12:16 PM 5/1/2007 -0400, Joel Bender wrote:
>So issubclass(D, C) would call D.__issubclass__(C) or
>C.__rissubclass__(D) and leave it up to the programmer.
Yes, except there's only the '__r__' versions and they're not called that.
> The former is
>"somebody is checking to see if I inherit s
> To me, interfaces and/or generic functions strike the right balance.
I agree. As I've said before, if this was 1994 I think I'd be in the
PJE camp and prefer generic functions. As it is, I think interfaces
better fit the current state of Python. And I think the existing type
system has everyt
At 09:13 AM 5/1/2007 -0700, Talin wrote:
>Phillip J. Eby wrote:
>>Proceeding to the "Next" Method
>>~~~
>>If the first parameter of an overloaded function is named
>>``__proceed__``, it will be passed a callable representing the next
>>most-specific method. For example,
2007/5/1, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> The point is that even though many people get some passive knowledge
> of English over time, they have a hard time with active usage of the
> language. So when they need to come up with identifiers and put comments
> into the code, they use their f
I just wanted to throw in a note for those who are upset with the idea that
classes should be able to decide how isinstance() and issubclass()
work. If you want "true, unforgeable" isinstance and subclass, you can
still use these formulas:
def true_issubclass(C1, C2):
return C2 in type._
Jim Jewett schrieb:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> The identifier syntax is \*.
>
>> ID_Start is defined as all characters having one of the general
>> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
>> letters (Lt), modifier letters (Lm), oth
Phillip J. Eby wrote:
> Proceeding to the "Next" Method
> ~~~
>
> If the first parameter of an overloaded function is named
> ``__proceed__``, it will be passed a callable representing the next
> most-specific method. For example, this code::
>
> def foo(bar:obje
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The identifier syntax is \*.
> ID_Start is defined as all characters having one of the general
> categories uppercase letters (Lu), lowercase letters (Ll), titlecase
> letters (Lt), modifier letters (Lm), other letters (Lo), letter
> numb
> Reading from
> http://mail.python.org/pipermail/python-3000/2006-April/001474.html,
> the message that prompted this particular addition to PEP 3099, "I
> want good Unicode support for string literals and comments. Everything
> else in the language ought to be ASCII."
>
> Identifiers aren't stri
Phillip J. Eby wrote:
>> Personally, I still think that the most uniform way of spelling this
>> is overloading isinstance and issubclass; that has the highest
>> likelihood of standardizing the spelling for such inquiries.
>
> A big +1 here. This is no different than e.g. operator.mul() being a
>> Python code is written by many people in the world who are not
>> familiar with the English language, or even well-acquainted with the
>> Latin writing system.
> [snip]
>
> That makes absolutely no sense. You mean to tell me that people write
> Python without being able to understand any of the
At 10:11 AM 5/1/2007 -0400, Jim Jewett wrote:
>On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 07:29 PM 4/30/2007 -0400, Jim Jewett wrote:
>> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> >>PEP 3115, however, requires that a class' metaclass be determined
>> >>*before* the
At 12:31 AM 5/1/2007 -0700, Raymond Hettinger wrote:
>The alternative is to code the automatic finalization steps using
>weakref callbacks. For those used to using __del__, it takes a little
>while to learn the idiom but essentially the technique is hold a proxy
>or ref with a callback to a boundm
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Title: Supporting Non-ASCII Identifiers
> >
> > Isn't this already blacklisted in PEP 3099?
>
> It's not clear to me. That was in response to a suggestion
> that non-ASCII symbols will be used in the syntax of Python,
> i.e. in a way maki
Collin Winter schrieb:
> On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> PEP: Remove Implicit String Concatenation
>
> Jim Jewett has already submitted a PEP that does this, PEP 3126. It's
> in SVN but not showing up on PEP 0 for some reason:
It does show on PEP 0:
http://www.python
>> Title: Supporting Non-ASCII Identifiers
>
> Isn't this already blacklisted in PEP 3099?
It's not clear to me. That was in response to a suggestion
that non-ASCII symbols will be used in the syntax of Python,
i.e. in a way making it mandatory to be able to type these
symbols.
This is not the i
On 5/1/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Rationale
> > =
> That makes absolutely no sense. You mean to tell me that people write
> Python without being able to understand any of the language's
> keywords, builtin func
In talking to Neal Norwitz about this, I don't see a need for a
separate PEP for class decorators; we already have a decorators PEP,
#318. The following is a proposed patch to PEP 318 that adds in class
decorators.
Collin Winter
Index: pep-0318.txt
===
On 5/1/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> > - Implement TimSort for BLists, so that best-case sorting is O(n)
> > instead of O(log n).
>
> Is that a typo? Why would you want to make best-case sorting worse?
Yes, it should read O(n log n), not O(log n).
--
Daniel Stutzbach, Ph.D.
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Rationale
> =
>
> Python code is written by many people in the world who are not
> familiar with the English language, or even well-acquainted with the
> Latin writing system.
[snip]
That makes absolutely no sense. You mean to tell
On 5/1/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> The alternative is to code the automatic finalization steps using
> weakref callbacks. For those used to using __del__, it takes a little
> while to learn the idiom but essentially the technique is hold a proxy
> or ref with a callback to a
> - Implement TimSort for BLists, so that best-case sorting is O(n)
> instead of O(log n).
Is that a typo? Why would you want to make best-case sorting worse?
Paul.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listi
On 4/30/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> PEP: Remove Implicit String Concatenation
Jim Jewett has already submitted a PEP that does this, PEP 3126. It's
in SVN but not showing up on PEP 0 for some reason:
http://svn.python.org/view/peps/trunk/pep-3126.txt?rev=55030&view=markup
On 5/1/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Use Cases with Ambiguous Interpretations
> * The presence of a __getitem__ method is ambiguous in that it can be
> interpreted as either having sequence or mapping behavior. The ambiguity is
> easily resolved with an attribute claiming
On 4/30/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The idea of overloading isinstance and issubclass is running into some
> resistance. I still like it, but if there is overwhelming discomfort,
> we can change it so that instead of writing isinstance(x, C) or
> issubclass(D, C) (where C ove
On 4/30/07, Talin <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Patrick Maupin wrote:
> >> Method calls are deliberately disallowed by the PEP, so that the
> >> implementation has some hope of being securable.
> > If attribute access is allowed, arbitrary code can already
> > be triggered, s
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:29 PM 4/30/2007 -0400, Jim Jewett wrote:
> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>PEP 3115, however, requires that a class' metaclass be determined
> >>*before* the class body has executed, making it impossible to us
On 01/05/2007 12.52, Martin v. Löwis wrote:
> PEP: 31xx
> Title: Supporting Non-ASCII Identifiers
Isn't this already blacklisted in PEP 3099?
--
Giovanni Bajo
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo
On 01/05/2007 9.31, Raymond Hettinger wrote:
> PEP: Eliminating __del__
*sigh* I'm still -1, but I won't revive the discussion of course.
I would still like if the PEP listed the alternative me and others were
proposing, that is changing the semantic of __del__ (or dropping __del__ in
favor o
PEP: 31xx
Title: Supporting Non-ASCII Identifiers
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 3.0
Post-History:
Abstract
This PEP suggests to support
> Historically, __del__ has been one of the more error-laden dark corners
> of the language. From an implementation point of view, it has
> proven to be a thorny maintenance problem that grew almost beyond
> the range of human comprehension once garbage collection was introduced.
+1
Martin
_
1 - 100 of 104 matches
Mail list logo
