Re: [Python-Dev] Python 3 design principles
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] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] Python 3 design principles
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 centurys changing slightly evolutionary and > continously. Form this point of view PL development is still in a state > of modernistic, youthfull irresponsibility. I mostly agree with that. For me personally, one of the big reasons for jumping ship from perl to python (a considerable investment in time and effort) was to avoid perl 6. Its been clear for a long time that perl 6 will be completely different to perl 5, thus making perl 5 an evolutionary dead end. Yes I know about the perl 5 on perl 6 stuff - but who wants to program in a dead language? 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 using the wrong language for all these years). 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. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ 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] Proof of the pudding: str.partition()
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 one :).
The best alternative to rpartition I've encountered so far is Reinhold's
proposal of a 'separator index' that selects which occurrence of the separator
in the string should be used to perform the partitioning. However, even it
doesn't measure up, as you will see if you read on. . .
The idea is that, rather than "partition(sep)" and "rpartition(sep)", we have
a single method "partition(sep, [at_sep=1])".
The behaviour could be written up like this:
"""
Partition splits the string into three pieces (`before`, `sep`, `after`) - the
part of the string before the separator, the separator itself and the part of
the string after the separator. If the relevant portion of the string doesn't
exist, then the corresponding element of the tuple returned is the empty string.
The `at_sep` argument determines which occurence of the separator is used to
perform the partitioning. The default value of 1 means the partitioning occurs
at the 1st occurence of the separator. If the `at_sep` argument is negative,
occurences of the separator are counted from the end of the string instead of
the start. An `at_sep` value of 0 will result in the original string being
returned as the part 'after' the separator.
"""
A concrete implementation is below. Comparing it to Raymond's examples that
use rpartition, I find that the only benefit in these examples is that the use
of the optional second argument is far harder to miss than the single
additional letter in the method name, particularly if partition and rpartition
are used close together. Interestingly, out of 31 examples in Raymond's patch,
only 7 used rpartition.
The implementation, however, is significantly less obvious than that for the
simple version, and likely slower due to the extra conditional, the extra list
created, and the need to use join.
It also breaks symmetry with index/rindex and split/rsplit.
Additionally, if splitting on anything other than the first or last occurence
of the separator was going to be a significant use case for str.partition,
wouldn't the idea have already come up in the context of str.find and str.index?
I actually thought the 'at_sep' argument was a decent idea when I started
writing this message, but I have found my arguments in favour of it to be
wholly unconvincing, and the arguments against it perfectly sound ;)
Cheers,
Nick.
def partition(s, sep, at_sep=1):
""" Returns a three element tuple, (head, sep, tail) where:
head + sep + tail == s
sep == '' or sep is t
bool(sep) == (t in s) # sep indicates if the string was
found
>>> s = 'http://www.python.org'
>>> partition(s, '://')
('http', '://', 'www.python.org')
>>> partition(s, '?')
('http://www.python.org', '', '')
>>> partition(s, 'http://')
('', 'http://', 'www.python.org')
>>> partition(s, 'org')
('http://www.python.', 'org', '')
"""
if not isinstance(t, basestring) or not t:
raise ValueError('partititon argument must be a non-empty
string')
if at_sep == 0:
result = ('', '', s)
else:
if at_sep > 0:
parts = s.split(sep, at_sep)
if len(parts) <= at_sep:
result = (s, '', '')
else:
result = (sep.join(parts[:at_sep]), sep, parts[at_sep])
else:
parts = s.rsplit(sep, at_sep)
if len(parts) <= at_sep:
result = ('', '', s)
else:
result = (parts[0], sep, sep.join(parts[1:]))
assert len(result) == 3
assert ''.join(result) == s
assert result[1] == '' or result[1] is sep
return result
import doctest
print doctest.testmod()
==
Standard lib comparisons
==
=CGIHTTPServer.py=
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
! rest, _, query = rest.rpartition('?')
! script, _, rest = rest.partition('/')
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
if not os.path.exists(scriptfile):
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
! rest, _, query = rest.partition('?', at_sep=-1)
! script, _, rest = rest.partition('/')
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
if not os.path.exists(scriptfile):
=cookielib.py=
else:
path_specified = False
path = request_path(request)
!
Re: [Python-Dev] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4
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 ('pre'), which in turn would require adding a warning, which
would require checking that the warning didn't mess anything else up.
I thought it was a bit too much upheaval for a module that no one
should be using any more.
If Anthony or Guido or someone tells me to bite the bullet and make
the test run, I'll do it, of course.
--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] Python 3 design principles
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. You can't get much simpler to explain or use than the current print statement. -Barry signature.asc Description: This is a digitally signed message part ___ 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] C coding experiment
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 improved by recoding the set_lookkey() function to optimize key insertion order using Brent's variation of Algorithm D (See Knuth vol. III, section 6.4, page 525). It has the potential to boost performance for uniquification applications with duplicate keys being identified more quickly (usually with just a single probe). The function may also result in more frequent retirement of dummy entries during insertion operations. The function can be coded from scratch or adapted from Lua's source code. 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] String views
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? Didn't several of Raymond's examples use the idiom: part_1, _, s = s.partition(first_sep) part_2, _, s = s.partition(second_sep) part_3, _, s = s.partition(third_sep) --- Skip writes: > 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. If the referent is NULL, > ob_sval is freed. Won't work. A string may have multiple referrents, so a single referent field isn't sufficient. --- My own contribution: I know that the Java string class has support for this. The String class contains a reference to a char array along with start and length indices. The substring() method constructs what we're calling "string views". I wonder whether there is a way to instrument a JVM to record how often the underlying buffers are shared, then run some common Java apps. Since the feature is exactly analogous to what is being proposed here, I would find such such analysis very helpful. -- Michael Chermside ___ 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] String views
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 separate > subclass of basestring with their own representation. > That's probably a good idea anyway, since you wouldn't > want slicing to return substrings by default -- it > should be something you have to explicitly ask for. You all are reinventing NSString. That's the NextStep string type used by ObjC. PyObjC bridges to NSString with some difficulty. I have never used this myself, but from Donovan Preston I understand that NSString is just a base class or an interface or something like that and many different implementations / subclasses exist. Donovan has suggested that we adopt something similar for Python -- I presume in part to make his life wrapping NSString easier, but at least in part because the concept really works well in ObjC. I'm not saying to go either way yet. I'm wary of complexifications of the string implementation based on a horriffically complex implementation in ABC that was proven to be asymptotically optimal, but unfortunately was beat every time in practical applications by something much simpler, *and* the algorithm was so complex that we couldn't get the code 100% bugfree. But that was 20 years ago. -- --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
[Python-Dev] Replacement for print in Python 3.0
[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 that > > works like the old print statement, unless some serious > > magic is going on... [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! A transitional strategy could be to start designing the new API and introduce it in Python 2.x. Here's my strawman: (1) Add two new methods the the stream (file) API and extend write(): stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str, [a1, a2, ...])) stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., "\n") stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt % (a1, a2, ...)) (2) Add builtin functions write(), writeln(), writef() that call the corresponding method on sys.stdout. (Note: these should not just be the bound methods; assignment to sys.stdout should immediately affect those, just like for print. There's an important use case for this.) -- --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
[Python-Dev] Status of PEP 328
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_import". Thx and regards, Nicolas ___ 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 3 design principles
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 using the wrong language for all these > years). IMO it won't feel like a different language; syntactically, the most far-fetched change is probably dropping the print statement (on which I just opened a new thread). > 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. That might not be so easy given the desire to change most list-returning functions and methods into iterator-returning ones. This means that *most* places where you use keys() your code will still run, but *some* places you'll have to write list(d.keys()). How is the translator going to know? Worse, there's a common idiom: L = D.keys() L.sort() that should be replaced by L = sorted(D) how is the translator going to recognize that (given that there are all sorts of variations)? -- --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] Status of PEP 328
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 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_import". > > Thx and regards, > Nicolas > > ___ > 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] Replacement for print in Python 3.0
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 to strongly disagree. The print statement is simple, easy to understand, and easy to use. For use cases like debugging or the interactive interpreter, and even for some more complicated use cases like print>>, I think it's hard to beat the useability of print with a write() function, even if builtin. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Replacement for print in Python 3.0
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 to ABC and even
> > (unvisual) Basic. Out with it!
>
> I have to strongly disagree. The print statement is simple, easy to
> understand, and easy to use.
I agree with Barry. In particular, the behaviour of adding spaces
between items is something I find very useful, and it's missing from
the functional forms.
print greeting, name
feels much more natural to me than
write(greeting, " ", name)
or
writef("%s %s", greeting, name)
And that's even worse if the original used a literal "Hello", and only
later migrated to a variable greeting - remembering to get the spaces
in the right place is a pain:
print "Hello", name ==> print greeting, name
write("Hello ", name) ==> write(greeting, name) # oops, forgot the space
or write(greeting, " ", name) #
non-obvious translation
OK, it's a minor thing, but what's the benefit?
I've used print functions a lot in things like VBScript and
Javascript, and hated them every time...
Paul.
___
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] Replacement for print in Python 3.0
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 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 goal).
In any case, I think "write" would be better than "print", because it
is easier to type (at least for me; reaching for 'w' and than 'r' goes
much faster than reaching for 'p'). I don't like "writeln" though, as
in 9 of 10 cases I want the line break to be there. I'd rather have
write add the line break, and "writeraw" or somesuch exclude it.
By the way, if print has to go, then what about the assert, raise, and
import statements? Should these be changed to use function call syntax
as well? (By the way, assert and raise could be methods:
ZeroDivisionError.assert(denom != 0). Surprising that Java doesn't do
this ;-)
Fredrik
___
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] Replacement for print in Python 3.0
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 add something that >> > works like the old print statement, unless some serious >> > magic is going on... > > [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! Here I have to agree with Barry. print is very handy, and print>> is, too. I'd rather see exec and assert becoming a function. > A transitional strategy could be to start designing the new API and > introduce it in Python 2.x. Here's my strawman: > > (1) Add two new methods the the stream (file) API and extend write(): > stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str, > [a1, a2, ...])) > stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., "\n") > stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt % > (a1, a2, ...)) Do we really need writef()? It seems to be not much better than its %-formatting equivalent. > (2) Add builtin functions write(), writeln(), writef() that call the > corresponding method on sys.stdout. (Note: these should not just be > the bound methods; assignment to sys.stdout should immediately affect > those, just like for print. There's an important use case for this.) If write* is introduced, this is absolutely necessary. Reinhold -- Mail address is perfectly valid! ___ 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] Proof of the pudding: str.partition()
[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 people can do low-level
index tracking, optimization, or whatnot. Likewise, str.split() and
regexps remain better choices for some apps.
The discussion has centered around the performance cost of returning
three strings when two or fewer are actually used.
>From that discussion, we can immediately eliminate the center string
case as it is essentially cost-free (it is either an empty string or a
reference to, not a copy of the separator argument).
Another case that is no cause for concern is when one of the substrings
is often, but not always empty. Consider comments stripping for
example:
# XXX a real parser would need to skip over # in string literals
for line in open('demo.py'):
line, sep, comment = line.partition('#')
print line
On most lines, the comment string is empty, so no time is lost copying a
long substring that won't be used. On the lines with a comment, I like
having it because it makes the code easier to debug/maintain (making it
trivial to print, log, or store the comment string).
Similar logic applies to other cases where the presence of a substring
is an all or nothing proposition, such as cgi scripts extracting the
command string when present:
line, cmdfound, command = line.rpartition('?').
If not found, you've wasted nothing (the command string is empty). If
found, you've gotten what you were going to slice-out anyway.
Also, there are plenty of use cases that only involve short strings
(parsing urls, file paths, splitting name/value pairs, etc). The cost
of ignoring a component for these short inputs is small.
That leaves the case where the strings are long and parsing is repeated
with the same separator. The answer here is to simply NOT use
partition(). Don't write:
while s:
line, _, s = s.partition(sep)
. . .
Instead, you almost always do better with
for line in s.split(sep):
. . .
or with re.finditer() if memory consumption is an issue.
Remember, adding partition() doesn't take away anything else you have
now (even if str.find() disappears, you still have str.index()). Also,
its inclusion does not preclude more specialized methods like
str.before(sep) or str.after(sep) if someone is able to prove their
worth.
What str.partition() does do well is simplify code by encapsulating
several variations of a common multi-step, low-level programming
pattern. It should be accepted on that basis rather than being rejected
because it doesn't also replace re.finditer() or str.split().
Because there are so many places were partition() is a clear
improvement, I'm not bothered when someone concocts a case where it
isn't the tool of choice. Accept it for what it is, not what it is not.
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] Revising RE docs
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 re-used).
>
> Didn't Fredrik Lundh strongly imply that implicitly compiled objects
> are cached? That's a pretty big speed up right there.
What happened to RTSL? ("Read the Source, Luke" :)
They *are* cached and there is no cost to using the functions instead
of the methods unless you have so many regexps in your program that
the cache is cleared (the limit is 100).
--
--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] Replacement for print in Python 3.0
> 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 itself needs to be revisited. There is no shortage of people who have taken issue with the trailing s in %(myvar)s. 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] Proof of the pudding: str.partition()
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" - repair by adding pieces; "She pieced the china cup" wordnet.princeton.edu/perl/webwn Cheers, Bill ___ 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] Weekly Python Patch/Bug Summary
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 349: allow str() to return unicode (2005-08-22)
http://python.org/sf/1266570 opened by Neil Schemenauer
pdb: implement "until",fix for 1248119 (2005-08-23)
http://python.org/sf/1267629 opened by Ilya Sandler
tarfile: fix for bug #1257255 (2005-08-17)
CLOSED http://python.org/sf/1262036 reopened by loewis
Cache lines in StreamReader.readlines (2005-08-24)
http://python.org/sf/1268314 opened by Martin v. Löwis
extending os.walk to support following symlinks (2005-08-26)
http://python.org/sf/1273829 opened by Erick Tryzelaar
libtarfile.tex: external URL changed (2005-08-27)
CLOSED http://python.org/sf/1274550 opened by Lars Gustäbel
documentation fixes (2005-08-28)
CLOSED http://python.org/sf/1274630 opened by George Yoshida
Compile socket module under cygwin (2005-08-28)
http://python.org/sf/1275079 opened by Miki Tebeka
fix distutils typo "sortcut" -> "shortcut" (2005-08-29)
CLOSED http://python.org/sf/1275796 opened by Wummel
Adding new regrtest resource 'urlfetch' (2005-08-30)
http://python.org/sf/1276356 opened by Hye-Shik Chang
tarfile: adding filed that use direct device addressing (2005-08-30)
http://python.org/sf/1276378 opened by Urban Purkat
tkinter hello world example bug (2005-08-31)
http://python.org/sf/1277677 opened by Yusuke Shinyama
Patches Closed
__
Improve %s support for unicode (2005-03-09)
http://python.org/sf/1159501 closed by nascheme
markupbase misses comments (bug 736659) (2004-02-20)
http://python.org/sf/901369 closed by fdrake
chr, ord, unichr documentation updates (2004-10-31)
http://python.org/sf/1057588 closed by fdrake
tarfile: fix for bug #1257255 (2005-08-17)
http://python.org/sf/1262036 closed by loewis
tarfile.py: set sizes of non-regular files to zero. (2005-03-22)
http://python.org/sf/1168594 closed by loewis
Fix pydoc crashing on unicode strings (2004-11-13)
http://python.org/sf/1065986 closed by rhettinger
fix for 1016880 urllib.urlretrieve silently truncates dwnld (2004-11-07)
http://python.org/sf/1062060 closed by birkenfeld
New tutorial tests in test_generators.py (2005-01-31)
http://python.org/sf/1113421 closed by birkenfeld
more __contains__ tests (2005-02-18)
http://python.org/sf/1141428 closed by birkenfeld
A program to scan python files and list those require coding (2003-08-06)
http://python.org/sf/784089 closed by birkenfeld
distutils.dir_utils.mkpath to support unicode (2005-03-21)
http://python.org/sf/1167716 closed by loewis
use ReleaseItanium configuration for zlib IA64 build (2005-03-09)
http://python.org/sf/1160164 closed by loewis
Solaris 2.5.1 _SC_PAGESIZE vs. _SC_PAGE_SIZE (2003-08-11)
http://python.org/sf/786743 closed by loewis
Flakey urllib2.parse_http_list (2003-11-25)
http://python.org/sf/848870 closed by birkenfeld
urllib2.parse_http_list bugfix 735248 (2004-02-21)
http://python.org/sf/901480 closed by birkenfeld
Cookie.py: One step closer to RFC 2109 (2003-11-24)
http://python.org/sf/848017 closed by birkenfeld
Fix for off-by-one bug in urllib.URLopener.retrieve (2003-09-21)
http://python.org/sf/810023 closed by birkenfeld
Allow socket.inet_aton("255.255.255.255") on Windo (2003-06-17)
http://python.org/sf/756021 closed by birkenfeld
libtarfile.tex: external URL changed (2005-08-27)
http://python.org/sf/1274550 closed by birkenfeld
documentation fixes (2005-08-27)
http://python.org/sf/1274630 closed by birkenfeld
fix distutils typo "sortcut" -> "shortcut" (2005-08-29)
http://python.org/sf/1275796 closed by nnorwitz
Patch for (Doc) bug #1212195 (2005-06-26)
http://python.org/sf/1227545 closed by lemburg
bltinmodule.c whitespace normalization (2005-07-21)
http://python.org/sf/1242579 closed by birkenfeld
fileinput openfile patch, bz2fileinput (2005-06-22)
http://python.org/sf/1225466 closed by birkenfeld
shutil.copytree() quits too soon after an error. (2005-07-21)
http://python.org/sf/1242454 closed by birkenfeld
New / Reopened Bugs
___
_register is not safe (2005-08-23)
CLOSED http://python.org/sf/1267540 opened by Russell Owen
bdist_rpm hardcodes setup.py as the script name (2005-08-23)
http://python.org/sf/1267547 opened by Fernando Pérez
tarfile local name is local, should be abspath (2005-08-12)
CLOSED http://python.org/sf/1257255 reopened by birkenfeld
crash recursive __getattr__ (2005-08-24)
http://python.org/sf/1267
[Python-Dev] itertools.chain should take an iterable ?
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 ___ 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] itertools.chain should take an iterable ?
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 signature ?
This is more suited to comp.lang.python
Consider the below examples (and remember that strings are iterable)
>>> import itertools as it
>>> list(it.chain('ABC', 'XYZ'))
['A', 'B', 'C', 'X', 'Y', 'Z']
>>> list(it.chain(['ABC', 'XYZ']))
['ABC', 'XYZ']
>>> list(it.chain(['ABC'], ['XYZ']))
['ABC', 'XYZ']
>>>
Hope that helps,
-jackdied
___
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] partition() (was: Remove str.find in 3.0?)
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 > builtin, you don't need a separate module. In contrast, re is a > stand-alone extension which, of course, requires an import. That's an implementation oriented view. IMHO it is all a match-and-cut operation with fixed strings the simplest form of match expressions. From that point of view the distinction between the two is quite arbitrary. Of course, when turning from principles to daily practice again it is quite clear the distinction is useful. --eric ___ 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] Replacement for print in Python 3.0
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 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 write "%s" % (x,) which is tedious. > Also, the format coding scheme itself needs to be revisited. There is > no shortage of people who have taken issue with the trailing s in > %(myvar)s. Maybe the syntax used in the string.Template class is the way to go? -- --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] Replacement for print in Python 3.0
> > 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 write "%s" % > (x,) which is tedious. Right. That too. > > Also, the format coding scheme itself needs to be revisited. There is > > no shortage of people who have taken issue with the trailing s in > > %(myvar)s. > > Maybe the syntax used in the class is the way to go? 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 solutions used by other languages. With Py3.0, we have a real opportunity to break-away from doing things the way C does it. 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] Replacement for print in Python 3.0
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 solutions used by other languages. With Py3.0,
> we have a real opportunity to break-away from doing things the way C
> does it.
Hrm. Most other languages these days do floating point formatting the
way C does it. I'm happy to look for other ways to invoke the thing,
but I think that we shouldn't tinker with %6.2f. (In fact, the major
complaint is about the one place where I *did* tinker with it --
%(boo)s.)
Maybe the ${boo} form can be extended to allow ${boo%6.2f} ???
Unfortunately that would prevent a different extension of ${boo}: %{boo+far}.
--
--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] Replacement for print in Python 3.0
(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. (Assuming the file is opened in binary mode.) -- --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] Replacement for print in Python 3.0
> 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 for many years, a curious reason for abandoning it. There's a pointer to Python Regrets, but that document contains no justification for the change. (Actually, using pointers to Powerpoint slides to explain/justify anything is, er... -- what's a polite euphemism for "a sign of a weak mind"? :-) I agree that "print" is already a bit peculiar, but so what? If we wanted Scheme, we'd be programming in Scheme, not Python. The only other parts of PEP 3000 I take issue with are the removal of "reduce" (a little) and "lambda" (a bit more seriously). I use reduce a lot, but it's easy enough to cobble together oneself, given the changes in Python over the last 10 years. Bill ___ 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] Replacement for print in Python 3.0
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 Python!
(Though that slogan apparently didn't work out so well for
Oldsmobile...)
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 function. That is, suppose
print "foo", 3, dir(sys)
was automagically converted to
print ("foo", 3, dir(sys))
Not sure I like this kind of trickyness, though. Though it might be
useful for "assert", "raise", maybe "exec", too.
I also don't quite see the point of adding new top-level reserved
words or built-in functions like "write". It clutters the namespace
without being much of an improvement over "sys.stdout.write", IMO.
Some kind of printf would be nice to have, but with Python's forgiving
syntax is easy enough to add yourself.
> Maybe the syntax used in the string.Template class is the way to go?
If you'd consider extending the Template syntax to positional
parameters ($1, $2, etc.), then perhaps "print" could be modified to
use the template for formatting, if it occurs as the first argument:
print string.Template("arg $1, arg $2"), arg1, arg2
with an alternate form
printf "arg $1, arg $2", arg1, arg2
where the first arg is required to be a template pattern string. This
is a nice improvement over C printf in that you can re-use arguments.
What happens to Template() when the string module goes away? Do we
write "arg $1, arg $2".Template() instead?
Bill
___
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] Replacement for print in Python 3.0
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 by looking at the solutions used by other languages. With Py3.0,
>>we have a real opportunity to break-away from doing things the way C
>>does it.
>
>
> Hrm. Most other languages these days do floating point formatting the
> way C does it. I'm happy to look for other ways to invoke the thing,
> but I think that we shouldn't tinker with %6.2f. (In fact, the major
> complaint is about the one place where I *did* tinker with it --
> %(boo)s.)
>
> Maybe the ${boo} form can be extended to allow ${boo%6.2f} ???
>
> Unfortunately that would prevent a different extension of ${boo}: %{boo+far}.
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!"
Shane
___
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] Replacement for print in Python 3.0
[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 of adding spaces
> between items is something I find very useful, and it's missing from
> the functional forms.
While I agree that mostly the print statement is "simple, easy to
understand, and easy to use", I've seen the trailing-comma version
cause confusion for a lot of newbies. I wouldn't mind at all if the
trailing-comma version disappeared in Python 3.0 -- if you need this
kind of complicated output, you can always use sys.stdout.write and/or
string formatting.
The spaces-between-items point that Paul Moore makes is IMHO the best
argument against the proposed write*() functions. 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. That is, I think we need to keep
*something* with functionality like:
def XXX(*args):
sys.stdout.write('%s\n' % ' '.join(str(a) for a in args))
Note that this would keep the Hello World example simple:
XXX(greeting, name)
STeVe
--
You can wordify anything if you just verb it.
--- 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] Replacement for print in Python 3.0
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 it.
Some reasons to drop it have to do with the arcane syntax: (a) the
trailing comma (is there anyone who likes that?), and (b) the optional
">>file" part. While I've always defended the latter against powerful
opposition, that was only because print was already a statement and I
find it important to have a way to do whatever print does to an
arbitrary file. Of course, if print() were a function, we wouldn't
need special syntax, we could just use stream.print() with the same
signature; so that's one argument for dropping the syntax.
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 a format string, assuming you have all the pieces available at the
same time (which often you don't). Surely you don't want to suggest an
extension, for example doubling the comma could make the extra space
go away... :-)
It looks to me like most arguments for keeping print are motivated by
backwards compatibility (in its many guises, like the existence of 15
years of tutorials) and not by what would be best if we were to design
a language from scratch.
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).
I've been thinking about some ancient Python history recently, which
reminded me that one theme in Python's design is to have a minimalist
syntax without being syntax-free like Lisp. (In a very early version
of Python, 'dir' was a statement, just so that I wouldn't have to type
the parentheses. Glad I dropped that one!) I really believe that
dropping print in favor of a few built-in functions is an improvement
-- backwards compatibility be damned!
--
--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] Replacement for print in Python 3.0
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 function. That is, suppose
>
> print "foo", 3, dir(sys)
>
> was automagically converted to
>
> print ("foo", 3, dir(sys))
___
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] Replacement for print in Python 3.0
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 it that way. > Another real problem with print is that, while the automatic insertion > of spaces is nice for beginners, it often gets in the way I agree; why not just drop that feature for Python 3.0? > It looks to me like most arguments for keeping print are motivated by > backwards compatibility (in its many guises, like the existence of 15 > years of tutorials) and not by what would be best if we were to design > a language from scratch. Well, heck, if we were designing a language from scratch, would we start with Python? I rather liked SchemeXerox. This is Python 3.0, after all, not BizarroLang 1.0. IMO the novice usability of it, combined with the existence of other alteratives for experienced programmers, combined with a tip of the hat to Python's noble history (what you refer to as "backwards compatibility"), keeps it in. Bill ___ 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] Replacement for print in Python 3.0
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 basically all of Python's statements are for implementing logic (if, while, etc), controlling flow (return, yield, try, etc), and defining structure (def, class, etc). `print` stands pretty much alone as a statement which does none of these things -- in fact, it does nothing for the program but merely has the interesting side-effect of writing to stdout. It's an anomaly. It stands out in the language as a sore thumb waiting for Guido's hammer. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Replacement for print in Python 3.0
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
>
> which is one of the reasons ABC and BASIC have it that way.
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
--
---
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://pyropus.ca/software/
---
___
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] Replacement for print in Python 3.0
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 goal).
Given all the other syntax it would be too ambiguous. If you really
want this, please sit down and design a grammar. If you can't do that,
just believe me that it would be too nasty (with too many exceptional
cases) to bother.
> In any case, I think "write" would be better than "print", because it
> is easier to type (at least for me; reaching for 'w' and than 'r' goes
> much faster than reaching for 'p'). I don't like "writeln" though, as
> in 9 of 10 cases I want the line break to be there. I'd rather have
> write add the line break, and "writeraw" or somesuch exclude it.
Yuck. Also, write() and writeln() have a long history going back to
Pascal. Java has print() and println(). Plus stream.write("abc")
already has a meaning, and the elegance of my proposal is that that
meaning remains unchanged.
> By the way, if print has to go, then what about the assert, raise, and
> import statements? Should these be changed to use function call syntax
> as well? (By the way, assert and raise could be methods:
> ZeroDivisionError.assert(denom != 0). Surprising that Java doesn't do
> this ;-)
It can't work for import because it defines a new name; if import were
a function, then import(foo) would necessarily mean to evaluate foo
first, which isn't what you want.
It could work for raise (and even for break and continue) but I'd
rather keep control flow as statements; you never know what the
compiler could do with the information that a particular block doesn't
contain a raise statement.
It can't work for assert because you don't want the argument to be
evaluated in -O mode.
--
--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] Python 3 design principles
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 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.
>
> Reinhold
The trailing comma is convenient, but I don't think it's that big of a
deal to have two methods.
ui.write()
ui.writeln() # or ui.print()
I'm +1 on making it a method of a "user interface object". Not just a
function.
I want to be able to import an interface, then communicate to it in a
consistent way even though it may look quite different on the screen.
Having a set of standard io methods moves in that direction I think.
import console
ui = console()
ui.write("Hello World\n")
howami = ui.input("How are you today? %s")
import popup
ui = popup('YesNo') # Create a 'YesNo' popup.
ok = ui.input('Ok to proceed?') # Open it and wait for it.
ok2 = ui.input('Are you sure?') # Reopen it and reuse it.
if ok == ok2 == 'Yes':
...
Some possible common methods...
ui.write(data)# non blocking print/output, doesn't wait
ui.send() # non echo write; passwords, config, etc..
ui.input(prompt) # output something and wait for return value
ui.get() # non echo wait for value, or io.next()
ui.read() # non blocking get
As for functions without '()'s. (Just a thought) You could use '<<' or
'<<<' (or other symbol) as a way to move data between objects.
ui.write <<< 'Hello World/n' # ui.write('Hello World/n')
ui.writeln <<< counter# ui.writeln(counter.next())
ok = ui.input <<< 'press a key:' # ok = ui.input('press a key:')
The requirement could be that the item on the left is a callable, and
the item on the right is a sequence or generator.
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
Re: [Python-Dev] Replacement for print in Python 3.0
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 behaviour from everything else a
newbie sees in C++. It therefore causes lots of confusion. I wonder if
the magic of "print" might have the same effect on newcomers to
Python, whos first experience is "print 'Hello, world!'"... It would
be very interesting to know.
--
mvh Björn
___
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] Replacement for print in Python 3.0
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 nice about being able
> > to write
> >
> > print "the answer is", 3*4+10
> >
> > which is one of the reasons ABC and BASIC have it that way.
I don't use print much. For online applications I call a socket write
or for web apps store up all the HTML in a buffer and only write it out
at the end (to allow code anywhere to raise a Redirect exception).
I don't use print for quick and dirty debugging, but this
def dump(*args):
sys.stderr.write('%s\n' % (repr(args)))
> 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`.
Me too, for real usage. Tutorials would get messier but how quickly do
people move on from those anyway?
-jackdied
___
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] Replacement for print in Python 3.0
> 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 don't think cleanliness is
all that interesting -- usefulness trumps it every time. And if
cleanliness was the answer, there would be larger changes to make --
like removing all the syntax variations by standardizing on a common
syntax like Lisp's.
Bill
___
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] Replacement for print in Python 3.0
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 [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] Replacement for print in Python 3.0
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). But then, a format() function would be necessary (equivalent to sprintf) > Also, the format coding scheme itself needs to be revisited. There is > no shortage of people who have taken issue with the trailing s in > %(myvar)s. That's a nuisance, right. Reinhold -- Mail address is perfectly valid! ___ 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] Replacement for print in Python 3.0
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 output _to stdout_ sockets, GUI widgets, buffers? sure. stdout? Almost never. Most of these don't have write() methods so I've never had a reason to use the "print >>" syntax. -jackdied ___ 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] Replacement for print in Python 3.0
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 sprintf)
Does it have to be a function? I'd expect it to be a method, like
string.Template. E.g
>>> '%s: %i'.substitute('badger', 42)
badger: 42
>>> '%(name)s: %(count)i'.substitute(name='badger', count=42)
badger: 42
BTW, I'm quite happy with the current string formatting format. I
certainly haven't "taken issue with the trailing s in %(myvar)s". If
it wasn't there, when it is for %(count)i and %(ratio)f, I'd probably
wonder why.
STeVe
--
You can wordify anything if you just verb it.
--- 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] Replacement for print in Python 3.0
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 (to a one) all have a quite fundamental impact on what the code in question means. `print` doesn't. I write data filters in Python all the time -- but I virtually never use `print`. stdout.write() is more consistent /and/ parallel to stdin.read(). `print` should go away, at least as a statement. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] Replacement for print in Python 3.0
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 output. >> >> > I'd say: > yeah, real programmers don't generate output _to stdout_ > > sockets, GUI widgets, buffers? sure. stdout? Almost never. > Most of these don't have write() methods so I've never had a reason to > use the "print >>" syntax. That is absolutely true, print is becoming less and less useful in the context of GUI or web applications. Even in Just Debugging scenarios, you're probably better off using something with more flexibility, such as the logging module. Additionally, the fact that sys.stdout is for bytes and not a text (unicode) makes it even more complicated. You can, of course, replace sys.stdout with an encoding-aware wrapper via codecs.getwriter (), but that's often inconvenient. -bob ___ 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] Replacement for print in Python 3.0
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 this is my first real post to python-dev (bio
below). I've got two ideas relating to formatting that I'd thought I'd
air out.
The first is to add a separator argument to write[ln]:
>>> def w(*args, **kwargs):
... nextsep = ""
... sep = kwargs.get("sep","")
... output = ""
... for item in args:
... output += nextsep
... nextsep = sep
... output += str(item)
... print output
...
>>> w("foo", "bar")
foobar
>>> w("foo", "bar", sep=" ")
foo bar
>>> w("foo", "bar", sep="\n")
foo
bar
>>> w("foo", "bar", sep="\t")
foo bar
>>>
I'd have found this handy just this week at work. Not a huge deal to
work around, obviously, but it would have been handy.
The second is something along the lines of:
>>> f = 3.14159
>>> str(f)
'3.14159'
>>> str(f, ".2") # calls f.__str__(".2") which can do whatever it wants
'3.14'
>>> str(f, "%.2") # the percent is ignored?
'3.14'
Thoughts?
Eli Stevens
Bio:
Geek since I saw my first computer in 5th grade at school. Programmed
(poorly) from middle school through high school. Graduated from Univ.
of Missouri, Columbia with a bachelors in CS. C++ fan at the time.
Worked a startup in the valley for 3 years, heavily in Java. Mildly
disliked it (from the start), found python, loved it, got acquired by
Cisco, but still doing Java. I cashed out. Now at Yahoo doing Python
almost full time. Happy. No accepted patches to an open source
project (yet). Prefer the MIT license for my code (assuming any of it
gets to a point where I can release it :).
Whew. ;)
___
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] String views
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 writes: > Didn't several of Raymond's examples use the idiom: >part_1, _, s = s.partition(first_sep) >part_2, _, s = s.partition(second_sep) >part_3, _, s = s.partition(third_sep) Yes, but in those cases, generally the entire original string was being kept by at least some part_#, so there really wasn't any wasted space. The problem only really shows up when a single 5-byte string keeps a 10K buffer alive. If it supports 2000 such strings, then everything is fine. Skip writes: > 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. If the referent is NULL, > ob_sval is freed. Michael Chermside writes: > Won't work. A string may have multiple referrents, so a single referent > field isn't sufficient. I think you're looking at it backwards. A string would use a reference to a (series of characters) instead of ob_sval, just as dictionaries point to a table instead of small_table. The catch (as Tim mentioned) is that the underlying series of characters might be much larger than *this* string needs. If it isn't shared, then the extra is wasted. One way to deal with this might be have the strings clean up when they're called. If the string's length multiplied by the number of references to the buffer is much less than the size of the buffer, then the string should make its own small copy. Whether the complication is worth it, I don't know. -jJ ___ 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] Python 3 design principles
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 iterator-returning ones. I assume part of the cleanup will include adding a choke point for import hooks. That way people could do the conversion on modules that they aren't sure about. There would be a performance penalty, but things would still work, and could be sped up as it was justified. > This means that *most* places where you use keys() your code will > still run, but *some* places you'll have to write list(d.keys()). How > is the translator going to know? So do it everywhere, in the auto-import. > Worse, there's a common idiom: >L = D.keys() >L.sort() > that should be replaced by >L = sorted(D) L = list(D.keys()) L = sorted(L) Not as efficient. Not as pretty. With work, even a mechanical importer could do better. But the old code would still run correctly. -jJ ___ 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] Replacement for print in Python 3.0
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 not sure how well the equivalents would
work. (They can be defined; they just feel a little too
fragile, like C's input.)
> 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 a format string, assuming you have all the pieces
> available at the same time (which often you don't).
I usually take "I need to get rid of spaces" as an indication
that I care about exact (not just readable, but exact)
formatting, and *should* use either write or a format string
(possibly waiting to collect the data).
Putting the spaces back in (without a format string) would
be even worse. Charles Cazabon's pointed out that it *could*
be as simple as
writeln(' '.join( ... ))
but if there isn't a builtin alias, people (at least those not
intimidated by the magic required to get simple output)
*will* do things at least as bad as
writeln(a, " ", b, " ", c)
or as bugprone as
# oops, format string and debug vars got out of sync
writef(" Current Vals:%s %d %d%s", curval, i, k, name, age)
-jJ
___
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] Replacement for print in Python 3.0
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 a format string, assuming you have all the pieces
>>available at the same time (which often you don't).
>
> I usually take "I need to get rid of spaces" as an indication
> that I care about exact (not just readable, but exact)
> formatting, and *should* use either write or a format string
> (possibly waiting to collect the data).
>
> Putting the spaces back in (without a format string) would
> be even worse. Charles Cazabon's pointed out that it *could*
> be as simple as
>
> writeln(' '.join( ... ))
Why not just offer an addition method ?
examine(x,y,z) # print with spaces
Or some other suitable name.
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
Re: [Python-Dev] String views (was: Re: Proof of the pudding:str.partition())
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> strings directly to traditional C API:s. I'm obviously missing something that's been there all along. Since Python strings can contain NULs, why do we bother to NUL-terminate them? Clearly, any tradition C API that expects to operate on NUL-terminated strings would break with a string containing an embedded NUL. 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] Python 3 design principles
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 you'd still have to rewrite old code to work with it, in which case you might as well change it to whatever the new way is in 3.0. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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 3 design principles
>> 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 statement. Then why remove it at all? 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] Python 3 design principles
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. ___ 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] String views
>> 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.
>> If the referent is NULL, ob_sval is freed.
Michael> Won't work. A string may have multiple referrents, so a single
Michael> referent field isn't sufficient.
Hmmm... I implemented it last night (though it has yet to be tested). I
suspect it will work. Here's my PyStringObject struct:
typedef struct {
PyObject_VAR_HEAD
long ob_shash;
int ob_sstate;
PyObject *ob_referent;
char *ob_sval;
} PyStringObject;
(minus the invariants which I have yet to check). Suppose url is a string
object whose value is "http://www.python.org/";, and that it has a reference
count of 1 and isn't a view onto another string. Its ob_referent field
would be NULL. (Maybe it would be better named "ob_target".) If we then
execute
before, sep, after = url.partition(":")
upon return before, sep and after would be string objects whose ob_referent
field refers to url and url's reference count would be 4. Their ob_sval
fields would point to the start of their piece of url. When the reference
counts of before, sep and after reach zero, they are reclaimed. Since they
each have a non-NULL ob_referent field, the target object is DECREFed, but
the ob_sval field is not freed. In the case of url, when its reference
count reaches zero, since its ob_referent field is NULL, its ob_sval field
is freed.
The only tricky business was PyString_AsString. If the argument object is a
view you have to "un-view" it by copying the interesting bits and DECREFing
the ob_referent. This is because of the NUL termination guarantee.
I wonder if the use of views would offset the overhead of returning to a
double-malloc allocation.
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] Replacement for print in Python 3.0
>> 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 suitable for the majority of my output. 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] Replacement for print in Python 3.0
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 before, and rejected on the grounds that it's too visually confusing having $ signs both inside and outside the quotes. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] String views
[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, the referent is DECREFed. > >> If the referent is NULL, ob_sval is freed. > > Michael> Won't work. A string may have multiple referrents, so a single > Michael> referent field isn't sufficient. > > Hmmm... I implemented it last night (though it has yet to be tested). I > suspect it will work. Here's my PyStringObject struct: *cough* buffers with string methods *cough* Seriously. I know people don't seem to like them much, but a buffer is a string view, an array view, an mmap view, ... It does /exactly/ what you suggest string views should do, and it's already in Python. With minor wrappers, one could use string methods almost directly, or with modification of string methods, buffers and strings could share methods. - Josiah ___ 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] Replacement for print in Python 3.0
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 doing this. There were two string concatenation operators: a regular one, and a "concatenate with a space between" operator. Using these, you could build up strings for output quite nicely. It helped somewhat that Hypertalk really only had strings as a data type. A Python version of this operator would need to be willing to convert either or both operands to strings. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Replacement for print in Python 3.0
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 Barry. In particular, the behaviour of adding spaces
>>between items is something I find very useful, and it's missing from
>>the functional forms.
>
... as proposed, but ...
>
> While I agree that mostly the print statement is "simple, easy to
> understand, and easy to use", I've seen the trailing-comma version
> cause confusion for a lot of newbies. I wouldn't mind at all if the
> trailing-comma version disappeared in Python 3.0 -- if you need this
> kind of complicated output, you can always use sys.stdout.write and/or
> string formatting.
>
... the trailing-comma version is indeed BASIC voodoo of ancient
heritage, and not something I'd personally miss.
> The spaces-between-items point that Paul Moore makes is IMHO the best
> argument against the proposed write*() functions. 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. That is, I think we need to keep
> *something* with functionality like:
>
> def XXX(*args):
> sys.stdout.write('%s\n' % ' '.join(str(a) for a in args))
>
> Note that this would keep the Hello World example simple:
>
> XXX(greeting, name)
>
Of course, for Python 3.0 if we lose the keyword there's nothing to stop
us calling the convenience function "print". With the removal of the
trailing-comma functionality we'd only have to add parentheses to 2.X
print statements to have them work :-)
Next question: could the function have a sensible return value, or is
None the best possible result?
hesitating-to-suggest-minus-one-ly y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.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] Replacement for print in Python 3.0
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`.
>
> Charles,
>
> I agree that it would be cleaner. I just don't think cleanliness is
> all that interesting -- usefulness trumps it every time. And if
Talking about cleanliness, I'm not sure which is cleaner::
print >> sys.stderr, "This is a long sentence that I " \
"had to cut in two."
print("This is a long sentence that I "
"had to cut in two.", stream=sys.stderr)
Sometimes I'll do this because I don't like the backslashes::
print >> sys.stderr, ("This is a long sentence that "
"Had to cut in two.")
Also, I find the ">>" syntax has always bothered me.
I find it useful but so out-of-place in the language.
+1 for removing the print statement.
___
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] String views
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 string comparisons can't be using anything that > relies on nul-termination, because Python strings can > contain embedded nuls. Possibly it uses memcmp(), but > that takes a length. > > You have a point when it comes to passing strings to > other C routines, though. For those that don't have a > variant which takes a maximum length, the substring type > might have to keep a cached nul-terminated copy created > on demand. Then the copying overhead would only be > incurred if you did happen to pass a substring to such > a routine. > Since Python strings *can* contain embedded NULs, doesn't that rather poo on the idea of passing pointers to their data to C functions as things stand? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] String views
> "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 face the issue of "Do I dare strfry() this char[]?" I don't see what difference it makes that the C program in question is being linked with Python, or that the source of the data is a Python string. He's chosen to program in C, let him get on with it. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] String views (was: Re: Proof of the pudding:str.partition())
[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 easy to pass Python
>Fredrik> strings directly to traditional C API:s.
>
> I'm obviously missing something that's been there all along. Since Python
> strings can contain NULs, why do we bother to NUL-terminate them? Clearly,
> any tradition C API that expects to operate on NUL-terminated strings would
> break with a string containing an embedded NUL.
sure, but that doesn't mean that such an API would break on a string that
*doesn't* contain an embedded NUL.
in practice, this is the difference between the "s" and "s#" argument
specifiers;
the former requires a NUL-free string, the latter can handle any byte string:
>>> f = open("myfile\0")
Traceback (most recent call last):
File "", line 1, in ?
TypeError: file() argument 1 must be (encoded string without NULL bytes),
not str
>>> f = open("myfile")
>>> f
___
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
