[EMAIL PROTECTED] wrote:
>Fredrik> Python strings are character buffers with a known length, not
>Fredrik> null-terminated C strings. the CPython implementation
>Fredrik> guarantees that the character buffer has a trailing NULL
>Fredrik> character, but that's mostly to make it eas
> "Steve" == Steve Holden <[EMAIL PROTECTED]> writes:
Steve> Since Python strings *can* contain embedded NULs, doesn't
Steve> that rather poo on the idea of passing pointers to their
Steve> data to C functions as things stand?
I think it's a "consenting adults" issue.
Ie, C progr
Greg Ewing wrote:
> [EMAIL PROTECTED] wrote:
>
>>If I then wanted to see what scheme's value
>>compared to, the string's comparison method would have to recognize that it
>>wasn't truly NUL-terminated, copy it, call strncmp() or whatever underlying
>>routine is used for string comparisons.
>
>
>
On 9/1/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Providing you can live with adding a pair of parentheses to that, you can
> > have:
> >
> >def print(*args):
> > sys.stdout.write(' '.join(args) + '\n')
> >
> > I think the language would be cleaner if it lacked this weird exception f
Steven Bethard wrote:
> [Guido van Rossum]
>
>>And good riddance! The print statement harks back to ABC and even
>>(unvisual) Basic. Out with it!
>
>
> [Barry Warsaw]
>
>>I have to strongly disagree. The print statement is simple, easy to
>>understand, and easy to use.
>
>
> [Paul Moore]
>
Steven Bethard wrote:
> I think we *do*
> need a statement or function of some sort that does the most basic
> task: writing a line to sys.stdout that calls str() on each of the
> elements and joins them with spaces.
Hypertalk (the programming language of Apple's Hypercard)
had an interesting way
[EMAIL PROTECTED] wrote:
> >> I'm skeptical about performance as well, but not for that reason. A
> >> string object can have a referent field. If not NULL, it refers to
> >> another string object which is INCREFed in the usual way. At string
> >> deallocation, if the referent i
Shane Hathaway wrote:
> May I also suggest the following shortcut for creating and evaluating a
> string template. (Ever since I thought of this, I've actually used this
> in code without thinking... it's just too natural):
>
>message = $"Hello, $name!"
As I recall, this has been consider
>> And good riddance! The print statement harks back to ABC and even
>> (unvisual) Basic. Out with it!
Barry> I have to strongly disagree. The print statement is simple, easy
Barry> to understand, and easy to use.
I'm with Barry. Even for non-debug use the print statement is su
>> I'm skeptical about performance as well, but not for that reason. A
>> string object can have a referent field. If not NULL, it refers to
>> another string object which is INCREFed in the usual way. At string
>> deallocation, if the referent is not NULL, the referent is DECRE
On Thursday 01 September 2005 23:00, [EMAIL PROTECTED] wrote:
> Then why remove it at all?
Bingo. I don't see any need to remove it. I could live with removing the
trailing-comma semi-wart, but there just isn't any need to remove it.
-Fred
--
Fred L. Drake, Jr.
___
>> I still hope to see this change to "make print a builtin instead of a
>> statement". I'd hate to lose the one-line hello world example due to
>> cruft like "from sys import stdout".
Barry> I agree. You can't get much simpler to explain or use than the
Barry> current print
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>There's no way importing a module could add something that
>>works like the old print statement, unless some serious
>>magic is going on...
>
> You'd have to enclose print arguments in parentheses. Of course, the "trailing
> comma" form would be
Fredrik> Python strings are character buffers with a known length, not
Fredrik> null-terminated C strings. the CPython implementation
Fredrik> guarantees that the character buffer has a trailing NULL
Fredrik> character, but that's mostly to make it easy to pass Python
Fredrik>
Jim Jewett wrote:
>
>>Another real problem with print is that, while the
>>automatic insertion of spaces is nice for beginners,
>>it often gets in the way, and what you have to do to
>>avoid this is pretty nasty: either drop print altogether
>>in favor of sys.stdout.write(), or use string concate
Guido van Rossum suggested:
>stream.write(a1, a2, ...)
>stream.writeln(a1, a2, ...)
>stream.writef(fmt, a1, a2, ...)
> builtin functions write(), writeln(), writef() that call the
> corresponding method on sys.stdout.
These seem good, except that write typically matches
read, and I
Nick Craig-Wood wrote:
> If come python 3, there is a 99% accurate program which can turn your
> python 2.x into python 3 code, then that would ease the transition
> greatly.
Guido wrote:
> That might not be so easy given the desire to change most
> list-returning functions and methods into iter
Tim Delaney writes:
> One of the big disadvantages of string views is that they need to keep
> the original object around, no matter how big it is. But in the case of
> partition, much of the time the original string survives for at least a
> similar period to the partitions.
Michael Chermside wri
Guido van Rossum wrote:
> It seems to me that, as long as write() and writeln() were built-ins
> taking multiple args, teaching a beginner to use
>
>
writeln("The answer is: ", 4+4)
>
>
> is perfectly clear (and might be a gentle introduction to function
> calls as well).
Hello,
I'm Eli
On Sep 1, 2005, at 2:27 PM, Jack Diederich wrote:
> On Thu, Sep 01, 2005 at 11:12:57PM +0200, Fredrik Lundh wrote:
>
>> Charles Cazabon wrote:
>>
>>
>>> in fact, it does nothing for the program but merely has the
>>> interesting
>>> side-effect of writing to stdout.
>>>
>>
>> yeah, real program
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Charles Cazabon wrote:
>
> > in fact, it does nothing for the program but merely has the interesting
> > side-effect of writing to stdout.
>
> yeah, real programmers don't generate output.
That wasn't quite my point - I meant that the rest of Python's s
Reinhold Birkenfeld wrote:
> Raymond Hettinger wrote:
> > Actually, formatting needs to become a function. The overloading of the
> > arithmetic mod operator has proven to be unfortunate (if only because of
> > precedence issues).
>
> But then, a format() function would be necessary (equivalent t
On Thu, Sep 01, 2005 at 11:12:57PM +0200, Fredrik Lundh wrote:
> Charles Cazabon wrote:
>
> > in fact, it does nothing for the program but merely has the interesting
> > side-effect of writing to stdout.
>
> yeah, real programmers don't generate output.
>
I'd say:
yeah, real programmers don't
Raymond Hettinger wrote:
>> Do we really need writef()? It seems to be not much better than its %-
>> formatting
>> equivalent.
>
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if only because of
> precedence issue
Charles Cazabon wrote:
> in fact, it does nothing for the program but merely has the interesting
> side-effect of writing to stdout.
yeah, real programmers don't generate output.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
> Providing you can live with adding a pair of parentheses to that, you can
> have:
>
>def print(*args):
> sys.stdout.write(' '.join(args) + '\n')
>
> I think the language would be cleaner if it lacked this weird exception for
> `print`.
Charles,
I agree that it would be cleaner. I j
On Thu, Sep 01, 2005 at 02:46:13PM -0600, Charles Cazabon wrote:
> Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I don't use "print" myself much, but for the occasional 3-line script.
> > But I think the user-friendliness of it is a good point, and makes up
> > for the weirdness of it all. There's s
Something I've noticed from teaching C++ to newbies, is that you
should NOT (never ever) start with "cout << "Hello, world!" << endl;".
You should start with "printf("Hello, world\n");" The cout thingy is
impossible to explain to a newbie because it uses much underlying
"magic" and has a very diffe
Reinhold Birkenfeld wrote:
> Greg Ewing wrote:
>
>>Charles Cazabon wrote:
>>
>>
>>>Perhaps py3k could have a py2compat module. Importing it could have the
>>>effect of (for instance) putting compile, id, and intern into the global
>>>namespace, making print an alias for writeln,
>>
>>There's no w
On 9/1/05, Fredrik Johansson <[EMAIL PROTECTED]> wrote:
> Why not instead change the language so as to allow any function call
> to be written without parentheses (when this is unambiguous)? This
> could make Python more convenient for creating imperative-style DSLs
> (though I'm not sure this is a
Bill Janssen <[EMAIL PROTECTED]> wrote:
> > And good riddance! The print statement harks back to ABC and even
> > (unvisual) Basic. Out with it!
I'm with Guido on this, BTW.
> After reviewing the PEP 3000 notes, I can find no justification there
> for removing "print"
Well, how about the fact th
I don't use "print" myself much, but for the occasional 3-line script.
But I think the user-friendliness of it is a good point, and makes up
for the weirdness of it all. There's something nice about being able
to write
print "the answer is", 3*4+10
which is one of the reasons ABC and BASIC hav
Bill Janssen <[EMAIL PROTECTED]> wrote:
> I don't use "print" myself much, but for the occasional 3-line script.
> But I think the user-friendliness of it is a good point, and makes up
> for the weirdness of it all. There's something nice about being able
> to write
>
> print "the answer is", 3
I see this is Fredrik's earlier suggestion.
Bill
I (reduntantly) wrote:
> Is there a syntax trick here? Suppose start-of-the-line function
> names not followed by an open-paren, but followed by comma-separated
> lists of expressions, were treated as if the rest of the line were
> arguments to a
On 9/1/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> After reviewing the PEP 3000 notes, I can find no justification there
> for removing "print" other than your statement here -- that it has
> served honorably and well in many programming languages for many
> years, a curious reason for abandoning
[Guido van Rossum]
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it!
[Barry Warsaw]
> I have to strongly disagree. The print statement is simple, easy to
> understand, and easy to use.
[Paul Moore]
> I agree with Barry. In particular, the behavi
Guido van Rossum wrote:
> On 9/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>string.Template is a bit too simplified. But perhaps it can be adapted.
>>We still want some way to express %r, %6.2f, etc.Since string
>>formatting has been around since Tim was in diapers, we should probab
I have to agree with Barry, Paul, Fredrik, Reinhold, etc. Removing
the "print" statement would immediately break at a fundamental level
15 years of tutorials, books, and examples, many of which start with
>>> print "Hello, World!"
Of course, maybe that's the idea -- this is not your father's Pyt
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it!
Guido,
After reviewing the PEP 3000 notes, I can find no justification there
for removing "print" other than your statement here -- that it has
served honorably and well in many programming langua
(Please don't send private replies.)
On 9/1/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> I have a lot of code that uses read()/write() to for binary file access.
> Will that break by this change?
> If so, I'd like to propose writes() instead of write() as proposed.
No, that's the beauty. (Assu
On 9/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> string.Template is a bit too simplified. But perhaps it can be adapted.
> We still want some way to express %r, %6.2f, etc.Since string
> formatting has been around since Tim was in diapers, we should probably
> start by looking at the
> > Actually, formatting needs to become a function. The overloading of
the
> > arithmetic mod operator has proven to be unfortunate (if only
because of
> > precedence issues).
>
> For me, it's not so much the precedence, but the fact that "%s" % x
> doesn't work as expected if x is a tuple; you'
On 9/1/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Do we really need writef()? It seems to be not much better than its %-
> > formatting
> > equivalent.
>
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if
Raymond Hettinger wrote:
>> I think it's convenient but also rather odd that split() with a static
>> string argument was moved from module string to a method in class str,
>> while split() with a regexp has remained in module re.
>
> I don't see what you find odd. With str and unicode objects bei
On Thu, Sep 01, 2005 at 07:58:40PM +0200, Paolino wrote:
> Working on a tree library I've found myself writing
> itertools.chain(*[child.method() for child in self]).
> Well this happened after I tried instinctively
> itertools.chain(child.method() for child in self).
>
> Is there a reason for t
Working on a tree library I've found myself writing
itertools.chain(*[child.method() for child in self]).
Well this happened after I tried instinctively
itertools.chain(child.method() for child in self).
Is there a reason for this signature ?
Regards paolino
On 9/1/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> LD "Gus" Landis wrote:
> > .piece() can be both a verb and a noun
>
> Er, pardon? I don't think I've ever heard 'piece' used
> as a verb in English. Can you supply an example sentence?
>
- assemble: make by putting pieces together; "She pieced a
> Do we really need writef()? It seems to be not much better than its %-
> formatting
> equivalent.
Actually, formatting needs to become a function. The overloading of the
arithmetic mod operator has proven to be unfortunate (if only because of
precedence issues).
Also, the format coding schem
Patch / Bug Summary
___
Patches : 903 open (+551) / 5222 closed (+2324) / 6125 total (+2875)
Bugs: 903 open (-23) / 5222 closed (+45) / 6125 total (+22)
RFE : 187 open ( -3) / 184 closed ( +5) / 371 total ( +2)
New / Reopened Patches
__
PEP
On 8/31/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
>
> Michael> (2) is what we have today, but I would prefer (1) to
> Michael> gently encourage people to use the precompiled objects
> Michael> (which are distin
[Steve Holden]
> The collective brainpower that's been exercised on this one
enhancement
> already must be phenomenal, but the proposal still isn't perfect.
Sure it is :-)
It was never intended to replace all string parsing functions, existing
or contemplated. We still have str.index() so peop
Guido van Rossum wrote:
> [Charles Cazabon]
>> >> Perhaps py3k could have a py2compat module. Importing it could have the
>> >> effect of (for instance) putting compile, id, and intern into the global
>> >> namespace, making print an alias for writeln,
>
> [Greg Ewing]
>> > There's no way importi
I like the present print statement because parentheses are
inconvenient to type compared to lowercase letters, and it looks less
cluttered without them. The parentheses in writeln("hello world")
don't add any more meaning than a terminating semicolon would, so why
are they necessary?
Why not inste
On 9/1/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-09-01 at 10:58, Guido van Rossum wrote:
>
> > [Reinhold Birkenfeld]
> > > You'd have to enclose print arguments in parentheses. Of course, the
> > > "trailing
> > > comma" form would be lost.
> >
> > And good riddance! The print st
On Thu, 2005-09-01 at 10:58, Guido van Rossum wrote:
> [Reinhold Birkenfeld]
> > You'd have to enclose print arguments in parentheses. Of course, the
> > "trailing
> > comma" form would be lost.
>
> And good riddance! The print statement harks back to ABC and even
> (unvisual) Basic. Out with it
It's been approved, but AFAIK still awaiting a patch.
So yes, please help!
On 9/1/05, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to know what is the status of PEP 328? Can absolute_import
> be expected in 2.5? Any help needed? I'll be interested.
>
> Also, the content of
On 9/1/05, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> I'm all for removing the cruft in python 3, and giving it a bit of a
> spring clean, but please, please don't make it feel like a different
> language otherwise the users will be deserting in droves (no-one likes
> to be told that they've been
Hi,
I would like to know what is the status of PEP 328? Can absolute_import
be expected in 2.5? Any help needed? I'll be interested.
Also, the content of the PEP doesn't seem to be up-to-date with the
status quo, since it is mentioned support in 2.4 for "from __future__
import absolute_impor
[Charles Cazabon]
> >> Perhaps py3k could have a py2compat module. Importing it could have the
> >> effect of (for instance) putting compile, id, and intern into the global
> >> namespace, making print an alias for writeln,
[Greg Ewing]
> > There's no way importing a module could add something th
On 8/31/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > Ah, I forgot the data is part of the PyString object itself, not stored as a
> > separate char* array. Without a char* in the object it's kind of hard to do
> > views.
>
> That wouldn't be a problem if substrings
Tim Delaney writes:
> One of the big disadvantages of string views is that they need to keep
> the original object around, no matter how big it is. But in the case of
> partition, much of the time the original string survives for at least a
> similar period to the partitions.
Why do you say that?
If anyone wants a small, but interesting C project, let me know. The
project does not require much familiarity with the CPython
implementation; all that is needed are basic C coding skills and a
puzzle solving mentality.
The goal is to determine whether the setobject.c implementation would be
i
On Thu, 2005-09-01 at 05:54, Nick Coghlan wrote:
> Oren Tirosh wrote:
> > * Replacing print with write/writeln
>
> I still hope to see this change to "make print a builtin instead of a
> statement". I'd hate to lose the one-line hello world example due to cruft
> like "from sys import stdout".
I
On Wed, Aug 31, 2005 at 07:56:04PM -0400, Jim Jewett wrote:
> What is the reasoning behind this?
>
> It seems to me that if a (passing) test is being added, maintenance releases
> are the *most* important places to run them.
In this case, it's because adding the test requires importing a new
mod
Charles Cazabon wrote:
>>also, a Boolean positional argument is a really poor clue about its meaning,
>>and it's easy to misremember the sense reversed.
>
>
> I totally agree. I therefore borrowed the time machine and modified my
> proposal to suggest it should be a keyword argument, not a posit
On Thu, Sep 01, 2005 at 08:55:48AM +0200, Kay Schluehr wrote:
> The idea of forking a language with a new release and thereby
> deevaluating older code seems somewhat archaic to me. Or the other way
> round: archaic materials and media like papyrus and scripture enabled
> communication across cent
Oren Tirosh wrote:
> * Replacing print with write/writeln
I still hope to see this change to "make print a builtin instead of a
statement". I'd hate to lose the one-line hello world example due to cruft
like "from sys import stdout".
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] |
67 matches
Mail list logo
