Greg Ewing [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
A bit of free thought brings me to the (half-baked) idea that if string
methods accepted any object which conformed to the buffer interface;
mmap, buffer, array, ... instances could gain all of the really
convenient methods
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 way importing a module could add something
[EMAIL PROTECTED] wrote:
As a Python programmer I'd get back what look like three strings: http,
:, and //www.python.org/. If each of them was a view onto part of the
original string, only the last one would truly refer to a NUL-terminated
sequence of characters. If I then wanted to see
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] |
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 positional
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
module
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 agree.
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
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?
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 were a
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
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
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!
I have
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 statement harks back
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
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 importing a module could
[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
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 distinctly faster when
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 scheme
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 quilt
-
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 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 this
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 being
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'd have to
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
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 languages
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 probably
start
[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 behaviour
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
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 have
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 that
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*4+10
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
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 way importing a
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 different
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 something
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 just
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.
/F
___
Python-Dev mailing list
Python-Dev@python.org
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 issues).
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 generate
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 to
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 statements
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 programmers don't generate
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 Stevens, and
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'm
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 concatenation
or
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 lost.
But
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 DECREFed.
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
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 considered
[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 is not NULL,
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 of
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]
I agree with
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 for
`print`.
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.
Python
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 programmers always
56 matches
Mail list logo
