Re: [Python-Dev] Proof of the pudding: str.partition()
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 that make strings the objects to use in many cases. Not a bad idea, but they couldn't literally be string methods. They'd have to be standalone functions like we used to have in the string module before it got mercilessly deprecated. :-) Not sure what happens to this when the unicode/bytearray future arrives, though. Treating a buffer of bytes as a character string isn't going to be so straightforward then. Here's my thought: One could modify string methods to check the type of the input (string, unicode, or other). That check turns on a flag for whether the method returns are string, unicode, or buffers. One uses PyObject_AsBuffer() methods to pull the char* and length for any input offering the buffer protocol. Now here's the fun part: One makes the methods aware of the type of the self parameter. One sets the 'split' method for the buffer object to be 'string_split', etc. Unicode does indeed get tricky, how does one handle buffers of unicode objects? Right now, you get the raw pointer and underlying length ( len (buffer(u'hello')) == 10 ). If there was a unicode buffer (perhaps ubuffer), that would work, but I'm not sure I really like it. I notice much of the discussion on 'string views', which to me seems like another way of saying 'buffer', and if there is a 'string view', there would necessarily need to be a 'unicode view'. As for the bytes type, from what I understand, they should directly support buffers without issue. - Josiah ___ Python-Dev mailing list Python-Dev@python.org 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
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 -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org 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: 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 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. (Maybe string comparisons are done inline. I'm sure there are some examples where the underlying C string routines are called.) Python strings are character buffers with a known length, not null-terminated C strings. the CPython implementation guarantees that the character buffer has a trailing NULL character, but that's mostly to make it easy to pass Python strings directly to traditional C API:s. (string views are nothing new in Python. the original Unicode string implementation supported this, but that was partially removed during integration. the type still uses a separate buffer to hold the characters, though (unlike 8-bit strings that store the characters in the string object itself)) /F ___ Python-Dev mailing list Python-Dev@python.org 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
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 Python-Dev@python.org 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)
! head, sep, _ = path.rpartition('/')
!
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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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
Python-Dev@python.org
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. /F ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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
Python-Dev@python.org
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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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
Python-Dev@python.org
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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
