Guido van Rossum schrieb:
> 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 ass
Guido van Rossum schrieb:
> 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
>>
Jason Orendorff wrote:
> Now I'm suspicious. Are you trying to
> turn Python into some kind of game?
You mean it isn't already? I've always felt that
writing Python code is more like fun than work...
--
Greg
___
Python-3000 mailing list
Python-3000@pyt
Phillip J. Eby wrote:
> Yep, that was my theory too, until I actually used generic functions.
Is there something about generic functions that makes
them different from methods in this regard? I've used
OO systems which have the equivalent of @before, @after
etc. for overriding methods, and others
Martin v. Löwis wrote:
...
> Specification of Language Changes
> =
>
> The syntax of identifiers in Python will be based on the Unicode
> standard annex UAX-31 [1]_, with elaboration and changes as defined
> below.
>
> Within the ASCII range (U+0001..U+007F), the v
Phillip J. Eby wrote:
> At 07:37 PM 5/1/2007 -0700, Guido van Rossum wrote:
>> That's one solution. Another solution would be to use GFs in Pydoc to
>> make it overloadable; I'd say pydoc could use a bit of an overhault at
>> this point.
>
> True enough; until you mentioned that, I'd forgotten th
Looking at PEP-3125, I see that one of the rejected alternatives is to allow
any unfinished expression to indicate a line continuation.
I would like to suggest a modification to that alternative that has worked
successfully in another programming language, namely Stu Feldman's EFL. EFL
is a langu
On 5/2/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > 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 i
Jim Jewett wrote:
> PEP: 30xz
> Title: Simplified Parsing
> Version: $Revision$
> Last-Modified: $Date$
> Author: Jim J. Jewett <[EMAIL PROTECTED]>
> Status: Draft
> Type: Standards Track
> Content-Type: text/plain
> Created: 29-Apr-2007
> Post-History: 29-Apr-2007
>
>
> Abstract
>
> Python ini
At 07:48 PM 5/2/2007 +1200, Greg Ewing wrote:
>Is there something about generic functions that makes
>them different from methods in this regard?
Yes.
1. When you're dispatching on more than one argument type, you're likely to
have more methods involved.
2. If you are using generic functions to
On 5/2/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> Implicit string concatenation is massively useful for creating long
> strings in a readable way though:
>
> call_something("first part\n"
>"second line\n"
> "third line\n")
>
> I find i
Steven Bethard wrote:
> On 5/2/07, Michael Foord <[EMAIL PROTECTED]> wrote:
>> Implicit string concatenation is massively useful for creating long
>> strings in a readable way though:
>>
>> call_something("first part\n"
>>"second line\n"
>>
[Georg]
> >> >>> a, *b, c = range(5)
> >> >>> a
> >> 0
> >> >>> c
> >> 4
> >> >>> b
> >> [1, 2, 3]
[Guido]
> > Has it been pointed out to you already that this particular example is
> > hard to implement if the RHS is an iterator whose length is not known
> > a priori?
On 5/2/07, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> Looking at PEP-3125, I see that one of the rejected alternatives is to allow
> any unfinished expression to indicate a line continuation.
>
> I would like to suggest a modification to that alternative that has worked
> successfully in another pr
> I am worried that (as no indent is required on the next line) it will
> accidentally introduce legal interpretations for certain common (?)
> typos, e.g.
> x = y+# Used to be y+1, the 1 got dropped
> f(x)
A reasonable worry. It could still be solved at the lexical level by
requiring ev
On 5/2/07, Brian Harring <[EMAIL PROTECTED]> wrote:
> Personally, I'm -1 on nuking implicit string concatenation; the
> examples provided for the 'why' aren't that strong in my experience,
> and the forced shift to concattenation is rather annoying when you're
> dealing with code limits (80 char li
At 10:34 AM 5/2/2007 -0700, Trent Mick wrote:
>But if you don't want the EOLs? Example from some code of mine:
>
> raise MakeError("extracting '%s' in '%s' did not create the "
> "directory that the Python build will expect: "
> "'%s'" % (src_pkg, dst_
On Wednesday 02 May 2007, Trent Mick wrote:
> raise MakeError("extracting '%s' in '%s' did not create the "
> "directory that the Python build will expect: "
> "'%s'" % (src_pkg, dst_dir, dst))
>
> I use this kind of thing frequently. Don't know i
On 5/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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.
+0
> He says "the tools
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Python initially inherited its parsing from C. While this has
> been generally useful, there are some remnants which have been
> less useful for python, and should be eliminated.
>
> + Implicit String concatenation
>
> + Line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 2, 2007, at 2:51 PM, Phillip J. Eby wrote:
> At 10:34 AM 5/2/2007 -0700, Trent Mick wrote:
>> But if you don't want the EOLs? Example from some code of mine:
>>
>> raise MakeError("extracting '%s' in '%s' did not create the "
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 2, 2007, at 3:23 PM, Alexey Borzenkov wrote:
> On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> Python initially inherited its parsing from C. While this has
>> been generally useful, there are some remnants which have been
>>
...
[Guido]
> I am worried that (as no indent is required on the next line) it will
> accidentally introduce legal interpretations for certain common (?)
> typos, e.g.
>
> x = y+# Used to be y+1, the 1 got dropped
> f(x)
The Icon language also uses this rule, and I never experienced
probl
On 02/05/2007 20.15, Guido van Rossum wrote:
> I am worried that (as no indent is required on the next line) it will
> accidentally introduce legal interpretations for certain common (?)
> typos, e.g.
>
> x = y+# Used to be y+1, the 1 got dropped
> f(x)
It would also change the meaning o
> OTOH, the "open bracket" rule is certainly sufficient by itself, and
> is invaluable for writing "big" list, tuple, and dict literals (things
> I doubt come up in Andrew's EFL inspiration).
If comma is treated as an operator, the "open bracket" rule doesn't seem all
that invaluable to me. Can y
> It would also change the meaning of existing valid programs such as:
>
>x = 1,
>y()
This is the strongest argument against the idea that I've seen so far.
It could be solved by *not* treating , as an operator, and by keeping the
open bracket rule.
On 5/2/07, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> I don't know if I can vote, but if I could I'd be -1 on this. Can't
> say I'm using continuation often, but there's one case when I'm using
> it and I'd like to continue using it:
>
> #!/usr/bin/env python
> """\
> Usage: some-too
[Tim Peters]
>> ...
>> OTOH, the "open bracket" rule is certainly sufficient by itself, and
>> is invaluable for writing "big" list, tuple, and dict literals (things
>> I doubt come up in Andrew's EFL inspiration).
[Andrew Koenig]
> If comma is treated as an operator, the "open bracket" rule doesn
> Incidentally, I know one Python programmer who writes list literals
> like this:
>
> mylist = [
>1
> , 2
> , 3
> ]
>
> In a fixed-width font, the commas and brackets are all in the same
> column. While "bleech" is the proper reaction ;-), that does work
Guido van Rossum schrieb:
>> > Also, what should this do? Perhaps the grammar could disallow it?
>> >
>> > *a = range(5)
>>
>> I'm not so sure about the grammar, I'm currently catching it in the AST
>> generation stage.
>
> Hopefully it's possible to only allow this if there's at least one comma?
Trent> But if you don't want the EOLs? Example from some code of mine:
Trent> raise MakeError("extracting '%s' in '%s' did not create the "
Trent> "directory that the Python build will expect: "
Trent> "'%s'" % (src_pkg, dst_dir, dst))
On 5/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/2/07, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> > I don't know if I can vote, but if I could I'd be -1 on this. Can't
> > say I'm using continuation often, but there's one case when I'm using
> > it and I'd like to continue using it:
On 5/1/07, Talin <[EMAIL PROTECTED]> wrote:
> 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
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> ]On Behalf
> Of Jim Jewett
> Sent: Monday, 30 April 2007 1:29 PM
> To: Python 3000; Python Dev
> Subject: [Python-Dev] PE
Phillip J. Eby wrote:
> At 07:48 PM 5/2/2007 +1200, Greg Ewing wrote:
>
> > I'd work on that by finding ways to reduce the boilerplate.
>
> Um... I did. They're called @before and @after. :)
I was talking about the need to put extra magic names
in the parameter list just to be able to call th
I fully support the removal of implicit string concatenation
(explicit is better than implicit; there's only one way to do it).
I also fully support the removal of backslashes for line continuation
of statements (same reasons). (I mean this as distinct from line
continuation within a string; that
Trent Mick wrote:
> But if you don't want the EOLs? Example from some code of mine:
>
> raise MakeError("extracting '%s' in '%s' did not create the "
> "directory that the Python build will expect: "
> "'%s'" % (src_pkg, dst_dir, dst))
>
> I use thi
Guido van Rossum wrote:
> In any case the grammar will probably end up accepting *a in lots of
> places where it isn't really allowed and you'll have to fix all of
> those. That sounds messy; only allowing *a at the end seems a bit more
> manageable.
I also would be quite happy if it were only al
I think it looks like not enough people are ready for both these
changes (PEP 3125 and PEP 3126). Maybe we could start by discouraging
these in the style guide (PEP 8) instead?
--Guido
On 5/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Trent Mick wrote:
>
> > But if you don't want the EOLs? Examp
[Skip]
> I use it all the time. For example, to build up (what I consider to be)
>readable SQL queries:
>
> rows = self.executesql("select cities.city, state, country"
>"from cities, venues, events, addresses"
>"where cities.city like %s"
>
Summary for the impatient: -1; the PEP is insufficiently motivated and
poorly specified.
> PEP: 3130
> Title: Access to Current Module/Class/Function
> Version: $Revision: 55056 $
> Last-Modified: $Date: 2007-05-01 12:35:45 -0700 (Tue, 01 May 2007) $
> Author: Jim J. Jewett <[EMAIL PROTECTED]>
> S
At 12:38 PM 5/3/2007 +1200, Greg Ewing wrote:
>In other words, I see the calling of the next method
>as an implementation detail that doesn't need to be
>announced prominently at the top of the method.
It's not an implementation detail - it's an expression of *intent*. E.g.,
in English, "After y
and hence '=' will not become an operator and hence '=' will not become
overloadable.
(unless, of course, Guido has revised previous rejections).
Came up again today on c.l.p. Surprised not alread in PEP.
tjr
___
Python-3000 mailing list
Python-30
>Raymond> I find that style hard to maintain. What is the advantage over
>Raymond> multi-line strings?
>
>Raymond> rows = self.executesql('''
>Raymond> select cities.city, state, country
>Raymond> from cities, venues, events, addresses
>Raymond> where cities.
Phillip J. Eby wrote:
> "After you start a transaction on a database, make
> sure you turn its logging up all the way."
>
> Please explain how you would improve one the clarity of that sentence
> *without* using the word "after" or any synonyms thereof.
I don't object to using the word "after"
Terry Reedy wrote:
> and hence '=' will not become an operator and hence '=' will not become
> overloadable.
Actually, '=' *is* overloadable in most cases, if
you can arrange for a suitably customised object
to be used as the namespace being assigned into.
About the only case you can't hook is as
[EMAIL PROTECTED] wrote:
> when I hit LF in an open
> multiline string a newline is inserted and the cursor is lined up under the
> "r" of "rows", not under the opening quote of the multiline string, and not
> where you chose to indent your example.
Seems to me that Python actually benefits from a
47 matches
Mail list logo
