Re: [Python-Dev] New Super PEP
On 29/04/2007 17.04, Guido van Rossum wrote: >> This is only a halfway fix to DRY, and it really only fixes the less >> important half. The important problem with super is that it >> encourages people to write incorrect code by requiring that you >> explicitly specify an argument list. Since calling super with any >> arguments other than the exact same arguments you have received is >> nearly always wrong, requiring that the arglist be specified is an >> attractive nuisance. > > Nearly always wrong? You must be kidding. There are tons of reasons to > call your super method with modified arguments. E.g. clipping, > transforming, ... Really? http://fuhm.net/super-harmful/ I don't believe that there are really so many. I would object to forcing super to *only* be able to pass unmodified arguments. But if it had an alternative syntax to do it (ala Dylan's next-method), I would surely use it often enough to make it worth. -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] head crashing
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 01, 2007 20:46 > But then you would substantially change the memory access behavior of > the > program in a debug build, that is, more than it is already changed by > the > fact that you have changed the memory layout of Python objects. Well, as we say in Iceland, that is a piece difference, not the whole sheep. In fact, most of the memory is already managed by the Object allocator, so there is only slight additional change. Further, at least one platform (windows) already employs a different memory allocator implementation for malloc in debug builds, namely a debug allocator. In addition, many python structures grow extra members in debug builds, most notably the PyObject _head. So you probably never have the exactly same blocksize pattern anyway. At any rate, the debug memory only changes memory access patterns by growing every block by a fixed amount. And why do we want to keep the same memory pattern? Isn't the memory allocator supposed to be a black box? The only reason I can see for maintaining the exact same pattern in a debug build is to reproduce some sort of memory access error, but that is precisely what the debug routines are for. Admittedly, I have never used the debug routines much. generally disable the object allocator for debug builds, and rely on the windows debug malloc implementation to spot errors for me, or failing that, I use Rational Purify, which costs money. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 29/04/2007 17.04, Guido van Rossum wrote: > > Nearly always wrong? You must be kidding. There are tons of reasons to > > call your super method with modified arguments. E.g. clipping, > > transforming, ... > > Really? > http://fuhm.net/super-harmful/ Hmmm. I've just counted more than 1600 usages of `super` in my sandbox. And all my tests pass. How does that square with the title of the rant you quote: Python's Super is nifty, but you can't use it ? Although the rest of `super-harmful` is slightly better than the title, the premise of James Knight is utterly wrong: Note that the __init__ method is not special -- the same thing happens with any method -- Christian Tanzerhttp://www.c-tanzer.at/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 02/05/2007 12.00, Christian Tanzer wrote: >>> Nearly always wrong? You must be kidding. There are tons of reasons to >>> call your super method with modified arguments. E.g. clipping, >>> transforming, ... >> Really? >> http://fuhm.net/super-harmful/ > > Hmmm. > > I've just counted more than 1600 usages of `super` in my > sandbox. And all my tests pass. And you don't follow any of the guidelines reported in that article? And you never met any of those problems? I find it hard to believe. The fact that your code *works* is of little importance, since the article is more about maintenance of existing code using super (and the suggestions he proposes are specifically for making code using super less fragile to refactorings). -- Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 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 continuation with "\"
>
> + 034 as an octal number (== decimal 28). Note that this is
> listed only for completeness; the decision to raise an
> Exception for leading zeros has already been made in the
> context of PEP XXX, about adding a binary literal.
>
>
> Rationale for Removing Implicit String Concatenation
>
> Implicit String concatentation can lead to confusing, or even
> silent, errors. [1]
>
> def f(arg1, arg2=None): pass
>
> f("abc" "def") # forgot the comma, no warning ...
> # silently becomes f("abcdef", None)
>
>
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 it an elegant way of building strings and would be sad to see it
go. Adding trailing '+' signs is ugly.
Michael Foord
> or, using the scons build framework,
>
> sourceFiles = [
> 'foo.c',
> 'bar.c',
> #...many lines omitted...
> 'q1000x.c']
>
> It's a common mistake to leave off a comma, and then scons complains
> that it can't find 'foo.cbar.c'. This is pretty bewildering behavior
> even if you *are* a Python programmer, and not everyone here is.
>
> Note that in C, the implicit concatenation is more justified; there
> is no other way to join strings without (at least) a function call.
>
> In Python, strings are objects which support the __add__ operator;
> it is possible to write:
>
> "abc" + "def"
>
> Because these are literals, this addition can still be optimized
> away by the compiler.
>
> Guido indicated [2] that this change should be handled by PEP, because
> there were a few edge cases with other string operators, such as the %.
> The resolution is to treat them the same as today.
>
> ("abc %s def" + "ghi" % var) # fails like today.
> # raises TypeError because of
> # precedence. (% before +)
>
> ("abc" + "def %s ghi" % var) # works like today; precedence makes
> # the optimization more difficult to
> # recognize, but does not change the
> # semantics.
>
> ("abc %s def" + "ghi") % var # works like today, because of
> # precedence: () before %
> # CPython compiler can already
> # add the literals at compile-time.
>
>
> Rationale for Removing Explicit Line Continuation
>
> A terminal "\" indicates that the logical line is continued on the
> following physical line (after whitespace).
>
> Note that a non-terminal "\" does not have this meaning, even if the
> only additional characters are invisible whitespace. (Python depends
> heavily on *visible* whitespace at the beginning of a line; it does
> not otherwise depend on *invisible* terminal whitespace.) Adding
> whitespace after a "\" will typically cause a syntax error rather
> than a silent bug, but it still isn't desirable.
>
> The reason to keep "\" is that occasionally code looks better with
> a "\" than with a () pair.
>
> assert True, (
> "This Paren is goofy")
>
> But realistically, that paren is no worse than a "\". The only
> advantage of "\" is that it is slightly more familiar to users of
> C-based languages. These same languages all also support line
> continuation with (), so reading code will not be a problem, and
> there will be one less rule to learn for people entirely new to
> programming.
>
>
> Rationale for Removing Implicit Octal Literals
>
> This decision should be covered by PEP ???, on numeric literals.
> It is mentioned here only for completeness.
>
> C treats integers beginning with "0" as octal, rather than decimal.
> Historically, Python has inherited this usage. This has caused
> quite a few annoying bugs for people who forgot the rule, and
> tried to line up their constants.
>
> a = 123
> b = 024 # really only 20, because octal
> c = 245
>
> In Python 3.0, the second line will instead raise a SyntaxError,
[Python-Dev] 64 bit warnings
There is a considerable amount of warnings present for 64 bit builds on windows. You can see them using VisualStudio 2005 even if you don't have the x64 compilers installed, by turning on "Detect 64 bit portability issues" in the general tab for pythoncore. Now, some of those just need straightforward upgrades of loop counters and so on to Py_ssize_t. Others probably require more judgement. E.g., do we want to change the signature of PyEval_EvalCodeEx() to accept Py_ssize_t counters rather than int? And if not, should we then use Py_SAFE_DOWNCAST() or just regular (int) typecast? Note that on x64 there is rarely any performance cost associated with usin 64 bit variables for function calls, since most of the time arguments are passed in registers. i.e. it is mostly structs that we want to keep unchanged, imo. Any thoughts? Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 it an elegant way of building strings and would be sad to see it
> go. Adding trailing '+' signs is ugly.
You'll still have textwrap.dedent::
call_something(dedent('''\
first part
second line
third line
'''))
And using textwrap.dedent, you don't have to remember to add the \n at
the end of every line.
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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"
>> "third line\n")
>>
>> I find it an elegant way of building strings and would be sad to see it
>> go. Adding trailing '+' signs is ugly.
>
> You'll still have textwrap.dedent::
>
> call_something(dedent('''\
> first part
> second line
> third line
> '''))
>
> And using textwrap.dedent, you don't have to remember to add the \n at
> the end of every line.
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 this kind of thing frequently. Don't know if others consider it
bad style.
Trent
--
Trent Mick
trentm at activestate.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
On Wed, May 02, 2007 at 04:42:09PM +0100, Michael Foord wrote: > Implicit string concatenation is massively useful for creating long > strings in a readable way though: This PEP doesn't seem very well-argued: "It's a common mistake to leave off a comma, and then scons complains that it can't find 'foo.cbar.c'." Yes, and then you say "oh, right!" and add the missing comma; problem fixed! The whole cycle takes about a minute. Is this really an issue worth fixing? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Please stop arguing about an opinionated piece of anti-super PR. On 5/2/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 02/05/2007 12.00, Christian Tanzer wrote: > > >>> Nearly always wrong? You must be kidding. There are tons of reasons to > >>> call your super method with modified arguments. E.g. clipping, > >>> transforming, ... > > >> Really? > >> http://fuhm.net/super-harmful/ > > > > Hmmm. > > > > I've just counted more than 1600 usages of `super` in my > > sandbox. And all my tests pass. > > And you don't follow any of the guidelines reported in that article? And you > never met any of those problems? I find it hard to believe. > > The fact that your code *works* is of little importance, since the article is > more about maintenance of existing code using super (and the suggestions he > proposes are specifically for making code using super less fragile to > refactorings). > -- > Giovanni Bajo > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
On Wed, May 02, 2007 at 01:53:01PM -0400, A.M. Kuchling wrote:
> On Wed, May 02, 2007 at 04:42:09PM +0100, Michael Foord wrote:
> > Implicit string concatenation is massively useful for creating long
> > strings in a readable way though:
>
> This PEP doesn't seem very well-argued: "It's a common mistake to
> leave off a comma, and then scons complains that it can't find
> 'foo.cbar.c'." Yes, and then you say "oh, right!" and add the missing
> comma; problem fixed! The whole cycle takes about a minute. Is this
> really an issue worth fixing?
The 'cycle' can also generally be avoided via a few good habits-
sourceFiles = [
'foo.c',
'bar.c',
#...many lines omitted...
'q1000x.c']
That's the original example provided; each file is on a seperate line
so it's a bit easier to tell what changed if you're reviewing the
delta. That said, doing
sourceFiles = [
'foo.c',
'bar.c',
#...many lines omitted...
'q1000x.c',
]
is (in my experience) a fair bit better; you *can* have the trailing
comma without any ill affects, plus shifting the ']' to a seperate
line is lessy noisy delta wise for the usual "add another string to
the end of the list".
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 limit for example)-
dprint("depends level cycle: %s: "
"dropping cycle for %s from %s" %
(cur_frame.atom, datom,
cur_frame.current_pkg),
"cycle")
Converting that over isn't hard, but it's a great way to inadvertantly
bite yourself in the butt- triple quote isn't usually much of an
option in such a case also since you don't want the newlines coming
through.
~harring
pgpeWCERdu4Ym.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
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_dir, dst))
>
>I use this kind of thing frequently. Don't know if others consider it
>bad style.
Well, I do it a lot too; don't know if that makes it good or bad, though. :)
I personally don't see a lot of benefit to changing the lexical rules for
Py3K, however. The hard part of lexing Python is INDENT/DEDENT (and the
associated unbalanced parens rule), and none of these proposals suggest
removing *that*. Overall, this whole thing seems like a bikeshed to me.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 if others consider it
> bad style.
I do this too; this is a good way to have a simple human-readable message
without doing weird things to about extraneous newlines or strange
indentation.
-1 on removing implicit string catenation.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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 continuation with "\" 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-tool.py [arguments...] Does this and that based on its arguments""" if condition: print __doc__ sys.exit(1) This way usage immediately stands out much better, without any unnecessary new lines. Best regards, Alexey. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing
-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 "
>> "directory that the Python build will expect: "
>> "'%s'" % (src_pkg, dst_dir, dst))
>>
>> I use this kind of thing frequently. Don't know if others consider it
>> bad style.
>
> Well, I do it a lot too; don't know if that makes it good or bad,
> though. :)
I just realized that changing these lexical rules might have an
adverse affect on internationalization. Or it might force more lines
to go over the 79 character limit.
The problem is that
_("some string"
" and more of it")
is not the same as
_("some string" +
" and more of it")
because the latter won't be extracted by tools like pygettext (I'm
not sure about standard gettext). You would either have to teach
pygettext and maybe gettext about this construct, or you'd have to
use something different. Triple quoted strings are probably not so
good because you'd have to still backslash the trailing newlines.
You can't split the strings up into sentence fragments because that
makes some translations impossible. Someone ease my worries here.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRjjpOHEjvBPtnXfVAQJ/xwP7BNMGvrmuxKmb7QiIawYjORKt9Pxmz7XJ
kFVHl47UusOGzgmtwm6Qi2DeSDsG0JOu0XwlZbX3YPE8omTzTP8WLdavJ1e+i2nP
V8GwXVyFgyFHx3V1jb0o9eiUGFEwkXInCGcOFqdWOEF49TtRNHGY6ne+eumwkqxK
qOyTGkcreG4=
=J6I/
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
-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 >> less useful for python, and should be eliminated. >> >> + Implicit String concatenation >> >> + Line continuation with "\" > > 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-tool.py [arguments...] > > Does this and that based on its arguments""" > > if condition: > print __doc__ > sys.exit(1) > > This way usage immediately stands out much better, without any > unnecessary new lines. Me too, all the time. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRjjpcnEjvBPtnXfVAQL0ngP9FwE7swQSdPiH4wAMQRe1CAzWXBLCXKok d08GHhyp5GWHs1UzDZbnxnLRVZt+ra/3iSJT8g32X2gX9gWkFUJfqZFN9wLVjzDZ qlX4m2cJs4nlskRDsycPMY9MLGUwQ8bt7mn92Oh3vXAvtXm42Dxu66NvTlyYdIFQ 9M2HrMbBn1M= =3kNg -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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))
Trent> I use this kind of thing frequently. Don't know if others
Trent> consider it bad style.
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"
" and events.active = 1"
" and venues.address = addresses.id"
" and addresses.city = cities.id"
" and events.venue = venues.id",
(city,))
I would be disappointed it string literal concatention went away.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 64 bit warnings
> Any thoughts? These should be fixed on a case-by-case basis. Please submit patches to SF, and assign them to me. Changes should only go into 2.6. As a principle, values that could exceed 2Gi in a hand-crafted Python program should be Py_ssize_t. Values that can never exceed the int range (because of other constraints, such as limitations of the byte code) should be safe-downcast to int (or smaller). In the particular case of PyEval_EvalCodeEx, I think most values can't grow beyond 2**31 because the byte code format wouldn't allow such indexes. There should be documentation on what the valid ranges are for argcount, kwcount, locals, and what the rationale for these limitations are, and then they should get a consistent datatype. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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] PEP 30XZ: Simplified Parsing
>
>
> 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 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 continuation with "\"
>
> + 034 as an octal number (== decimal 28). Note that this is
> listed only for completeness; the decision to raise an
> Exception for leading zeros has already been made in the
> context of PEP XXX, about adding a binary literal.
>
>
> Rationale for Removing Implicit String Concatenation
>
> Implicit String concatentation can lead to confusing, or even
> silent, errors. [1]
>
> def f(arg1, arg2=None): pass
>
> f("abc" "def") # forgot the comma, no warning ...
> # silently becomes f("abcdef", None)
>
> or, using the scons build framework,
>
> sourceFiles = [
> 'foo.c',
> 'bar.c',
> #...many lines omitted...
> 'q1000x.c']
>
> It's a common mistake to leave off a comma, and then
> scons complains
> that it can't find 'foo.cbar.c'. This is pretty
> bewildering behavior
> even if you *are* a Python programmer, and not everyone here is.
>
> Note that in C, the implicit concatenation is more
> justified; there
> is no other way to join strings without (at least) a
> function call.
>
> In Python, strings are objects which support the __add__ operator;
> it is possible to write:
>
> "abc" + "def"
>
> Because these are literals, this addition can still be optimized
> away by the compiler.
>
> Guido indicated [2] that this change should be handled by
> PEP, because
> there were a few edge cases with other string operators,
> such as the %.
> The resolution is to treat them the same as today.
>
> ("abc %s def" + "ghi" % var) # fails like today.
> # raises TypeError because of
> # precedence. (% before +)
>
> ("abc" + "def %s ghi" % var) # works like today;
> precedence makes
> # the optimization more
> difficult to
> # recognize, but does
> not change the
> # semantics.
>
> ("abc %s def" + "ghi") % var # works like today, because of
> # precedence: () before %
> # CPython compiler can already
> # add the literals at
> compile-time.
>
>
> Rationale for Removing Explicit Line Continuation
>
> A terminal "\" indicates that the logical line is continued on the
> following physical line (after whitespace).
>
> Note that a non-terminal "\" does not have this meaning,
> even if the
> only additional characters are invisible whitespace.
> (Python depends
> heavily on *visible* whitespace at the beginning of a
> line; it does
> not otherwise depend on *invisible* terminal whitespace.) Adding
> whitespace after a "\" will typically cause a syntax error rather
> than a silent bug, but it still isn't desirable.
>
> The reason to keep "\" is that occasionally code looks better with
> a "\" than with a () pair.
>
> assert True, (
> "This Paren is goofy")
>
> But realistically, that paren is no worse than a "\". The only
> advantage of "\" is that it is slightly more familiar to users of
> C-based languages. These same languages all also support line
> continuation with (), so reading code will not be a problem, and
> there will be one less rule to learn for people entirely new to
> programming.
>
>
> Rationale for Removing Implicit Octal Literals
>
> This decision should be covered by PEP ???, on numeric literals.
> It is mentioned here only for completeness.
>
> C treats integers beginning with "0" as octal, rather
> than decimal.
> Historically, Python has inherited this usage. This has caused
> quite a few annoying bugs for people who forgot the rule, and
> tried to line up their constants.
>
> a = 123
> b = 024 # really only 20, because octal
> c = 245
>
> In Python 3.0, the second line will instead raise a SyntaxError,
> because of the
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
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's a separate issue.) -- ?!ng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
[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"
>" and events.active = 1"
>" and venues.address = addresses.id"
>" and addresses.city = cities.id"
>" and events.venue = venues.id",
>(city,))
I find that style hard to maintain. What is the advantage over multi-line
strings?
rows = self.executesql('''
select cities.city, state, country
from cities, venues, events, addresses
where cities.city like %s
and events.active = 1
and venues.address = addresses.id
and addresses.city = cities.id
and events.venue = venues.id
''',
(city,))
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
Raymond> [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"
>>" and events.active = 1"
>>" and venues.address = addresses.id"
>>" and addresses.city = cities.id"
>>" and events.venue = venues.id",
>>(city,))
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.city like %s
Raymond> and events.active = 1
Raymond> and venues.address = addresses.id
Raymond> and addresses.city = cities.id
Raymond> and events.venue = venues.id
Raymond> ''',
Raymond> (city,))
Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
that caused me to start doing things this way (I've been doing my embedded
SQL statements this way for several years now), but 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. When I use individual strings the
parameters line up where I want them to (the way I lined things up in my
example). At any rate, it's what I'm used to now.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
FWIW, I'm -1 on both proposals too. I like implicit string literal concatenation
and I really can't see what we gain from backslash continuation removal.
Georg
Mark Hammond schrieb:
> 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] PEP 30XZ: Simplified Parsing
>>
>>
>> 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 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 continuation with "\"
>>
>> + 034 as an octal number (== decimal 28). Note that this is
>> listed only for completeness; the decision to raise an
>> Exception for leading zeros has already been made in the
>> context of PEP XXX, about adding a binary literal.
>>
>>
>> Rationale for Removing Implicit String Concatenation
>>
>> Implicit String concatentation can lead to confusing, or even
>> silent, errors. [1]
>>
>> def f(arg1, arg2=None): pass
>>
>> f("abc" "def") # forgot the comma, no warning ...
>> # silently becomes f("abcdef", None)
>>
>> or, using the scons build framework,
>>
>> sourceFiles = [
>> 'foo.c',
>> 'bar.c',
>> #...many lines omitted...
>> 'q1000x.c']
>>
>> It's a common mistake to leave off a comma, and then
>> scons complains
>> that it can't find 'foo.cbar.c'. This is pretty
>> bewildering behavior
>> even if you *are* a Python programmer, and not everyone here is.
>>
>> Note that in C, the implicit concatenation is more
>> justified; there
>> is no other way to join strings without (at least) a
>> function call.
>>
>> In Python, strings are objects which support the __add__ operator;
>> it is possible to write:
>>
>> "abc" + "def"
>>
>> Because these are literals, this addition can still be optimized
>> away by the compiler.
>>
>> Guido indicated [2] that this change should be handled by
>> PEP, because
>> there were a few edge cases with other string operators,
>> such as the %.
>> The resolution is to treat them the same as today.
>>
>> ("abc %s def" + "ghi" % var) # fails like today.
>> # raises TypeError because of
>> # precedence. (% before +)
>>
>> ("abc" + "def %s ghi" % var) # works like today;
>> precedence makes
>> # the optimization more
>> difficult to
>> # recognize, but does
>> not change the
>> # semantics.
>>
>> ("abc %s def" + "ghi") % var # works like today, because of
>> # precedence: () before %
>> # CPython compiler can already
>> # add the literals at
>> compile-time.
>>
>>
>> Rationale for Removing Explicit Line Continuation
>>
>> A terminal "\" indicates that the logical line is continued on the
>> following physical line (after whitespace).
>>
>> Note that a non-terminal "\" does not have this meaning,
>> even if the
>> only additional characters are invisible whitespace.
>> (Python depends
>> heavily on *visible* whitespace at the beginning of a
>> line; it does
>> not otherwise depend on *invisible* terminal whitespace.) Adding
>> whitespace after a "\" will typically cause a syntax error rather
>> than a silent bug, but it still isn't desirable.
>>
>> The reason to keep "\" is that occasionally code looks better with
>> a "\" than with a () pair.
>>
>> assert True, (
>> "This Paren is goofy")
>>
>> But realistically, that paren is no worse than a "\". The only
>> advantage of "\" is that it is slightly more familiar to users of
>> C-based languages. These same languages all also support line
>> continuation with (), so reading code will not be a problem, and
>> there will be one less rule to learn for people entirely new to
>> programming.
>>
>>
>> Rationale for Removing Implicit Octal Literals
>>
>> This decision should be covered by PEP ???, on numeric literals.
>> It is mentioned here only for completeness.
>>
>> C treats integers beginning with "0" as octal, rather
>> than decimal.
>> Historically, Python h
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
Georg Brandl wrote:
> FWIW, I'm -1 on both proposals too. I like implicit string literal
> concatenation
> and I really can't see what we gain from backslash continuation removal.
>
> Georg
-1 on removing them also. I find they are helpful.
It could be made optional in block headers that end with a ':'. It's
optional, (just more white space), in parenthesized expressions, tuples,
lists, and dictionary literals already.
>>> [1,\
... 2,\
... 3]
[1, 2, 3]
>>> (1,\
... 2,\
... 3)
(1, 2, 3)
>>> {1:'a',\
... 2:'b',\
... 3:'c'}
{1: 'a', 2: 'b', 3: 'c'}
The rule would be any keyword that starts a block, (class, def, if, elif,
with, ... etc.), until an unused (for anything else) colon, would always
evaluate to be a single line weather or not it has parentheses or line
continuations in it. These can never be multi-line statements as far as I
know.
The back slash would still be needed in console input.
The following inconsistency still bothers me, but I suppose it's an edge
case that doesn't cause problems.
>>> print r"hello world\"
File "", line 1
print r"hello world\"
^
SyntaxError: EOL while scanning single-quoted string
>>> print r"hello\
... world"
hello\
world
In the first case, it's treated as a continuation character even though
it's not at the end of a physical line. So it gives an error.
In the second case, its accepted as a continuation character, *and* a '\'
character at the same time. (?)
Cheers,
Ron
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Implicit String Concatenation and Octal Literals Was: PEP 30XZ: Simplified Parsing
>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.city like %s
>Raymond> and events.active = 1
>Raymond> and venues.address = addresses.id
>Raymond> and addresses.city = cities.id
>Raymond> and events.venue = venues.id
>Raymond> ''',
>Raymond> (city,))
[Skip]
> Maybe it's just a quirk of how python-mode in Emacs treats multiline strings
> that caused me to start doing things this way (I've been doing my embedded
> SQL statements this way for several years now), but 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. When I use individual strings the
> parameters line up where I want them to (the way I lined things up in my
> example). At any rate, it's what I'm used to now.
I completely understand. Almost any simplification or feature elimination
proposal is going to bump-up against, "what we're used to now".
Py3k may be our last chance to simplify the language. We have so many
special little rules that even advanced users can't keep them
all in their head. Certainly, every feature has someone who uses it.
But, there is some value to reducing the number of rules, especially
if those rules are non-essential (i.e. implicit string concatenation has
simple, clear alternatives with multi-line strings or with the plus-operator).
Another way to look at it is to ask whether we would consider
adding implicit string concatenation if we didn't already have it.
I think there would be a chorus of emails against it -- arguing
against language bloat and noting that we already have triple-quoted
strings, raw-strings, a verbose flag for regexs, backslashes inside multiline
strings, the explicit plus-operator, and multi-line expressions delimited
by parentheses or brackets. Collectively, that is A LOT of ways to do it.
I'm asking this group to give up a minor habit so that we can achieve
at least a few simplifications on the way to Py3.0 -- basically, our last
chance.
Similar thoughts apply to the octal literal PEP. I'm -1 on introducing
yet another way to write the literal (and a non-standard one at that).
My proposal was simply to eliminate it. The use cases are few and
far between (translating C headers and setting unix file permissions).
In either case, writing int('0777', 8) suffices. In the latter case, we've
already provided clear symbolic alternatives. This simplification of the
language would be a freebie (impacting very little code, simplifying the
lexer, eliminating a special rule, and eliminating a source of confusion
for the young amoung us who do not know about such things).
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 30XZ: Simplified Parsing
[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 an editor which doesn't try to be too clever about auto-formatting. I'm doing most of my Python editing at the moment using BBEdit Lite, which knows nothing at all about Python code -- but it works very well. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
