Re: [Python-Dev] String views
[EMAIL PROTECTED] wrote: >Greg> If a Python function is clearly wrapping a C function, one doesn't >Greg> expect to be able to pass strings with embedded NULs to it. > > Isn't that just floating an implementation detail up to the programmer (who > may > well not be POSIX- or Unix-aware)? so if POSIX refuses to deal with, e.g., NUL bytes in file names, Python should somehow work around that to avoid "exposing implementation details" ? ___ 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] reference counting in Py3K
While we're on the subject of Python 3000, what's the chance that reference counting when calling C functions from Python will go away? To me this is one of the few annoyances I have with Python. I know that Ruby somehow gets around the need for ref. counting. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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
Guido van Rossum wrote:
> If there are other use cases they can obviously be coded by using (b)
> and a modest amount of custom code. (I know there's the use case of
> printing sequences; I'll try to give an analysis of this use case in
> another post if one of its proponents doesn't do so soon.)
I did a fair bit of tinkering with that on the weekend. Printing a sequence of
strings is fine - it's the call to "map(str, seq)" that makes printing a
sequence of non-strings uglier than it should be. Doing it that way also
breaks the Python idiom of letting unicode remain as unicode.
However, one thing I eventually remembered was a discussion about a year ago
regarding the possibility of allowing str.join and unicode.join to accept
non-strings [1].
That discussion ended up leaving the join methods alone, because it is damn
hard to do it without slowing down the common case where the sequence is all
strings.
I'm currently considering proposing a "joinany" method for str and unicode
which accepts a sequence of arbitrary objects (I have a patch, but it needs
unit tests and docs, and I'm uncomfortable with the amount of code duplication
between the join and joinany methods).
[1] http://mail.python.org/pipermail/python-dev/2004-August/048516.html
> Some examples of the design pattern in action are str.strip(),
> str.lstrip() and str.rstrip(), or str.find() and str.rfind().
>
> A much stronger subcase of this pattern (with fewer exceptions) is
> that the return type of a function shouldn't depend on the value of an
> argument. I have a feeling that if we were to extend the notion of
> type to include invariants, you'd find that the basic pattern is
> actually the same -- often the variant behaviors change the key
> invariant relationships between input and output.
This becomes especially clear once "sorted" and "list.sort" are given as
examples where the various keyword arguments do not change the basic invariant
properties of the sorting operations - you start with a sequence, and you end
up with essentially the same sequence, only in a different order. The keyword
arguments simply control the precise meaning of "different order".
> (a) print(...)
> (b) printraw(...) or printbare(...)
> (c) printf(fmt, ...)
Hmm, I like those names better than anything else that has come up so far.
> Each can take a keyword parameter to specify a different stream than
> sys.stdout; but no other options are needed. The names for (a) and (c)
> are pretty much fixed by convention (and by the clamoring when I
> proposed write() :-). I'm not so sure about the best name for (b), but
> I think picking the right name is important.
'printraw' is good - it makes it clear it is part of the same family as
'print' and 'printf', and explains succintly how it differs from the normal
print function.
> We could decide not to provide (b) directly, since it is easily
> reduced to (c) using an appropriate format string ("%s" times the
> number of arguments). But I expect that use case (b) is pretty
> important, and not everyone likes having to use format strings. This
> could be reduced to a special case of the Swiss Army Knife (...Not)
> rule.
Additionally, doing 'printraw' with 'printf' is a little tricky - the best
I've come up with is "printf('%s'*3, a, b, c)".
> BTW we could use "from __future__ import printing" to disable the
> recognition of 'print' as a keyword in a particular module -- this
> would provide adequate future-proofing.
Gah, sometimes I miss the most obvious of solutions. . .
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] Pascaloid print substitute (Replacement for print inPython 3.0)
Raymond Hettinger wrote:
>> Print["One", "Two", ...]
>> Print["Buckle my shoe"]
>
> The ellipsis was a nice touch.
I've been wondering whether it would be worth allowing
ellipses to appear in other places besides slice indices,
so it could be used in a print-function and other such
purposes without having to abuse the slice notation:
print("One", "Two", ...)
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Fredrik Lundh wrote: > (you completely missed the point -- today's print mechanism works on *any* > object > that implements a "write" method, no just file objects. saying that "oh, all > you need is > to add a method" or "here's a nice mixin" doesn't give you a print > replacement) While we're on the subject, in Py3k I'd like to see readline(), readlines(), etc. removed from file objects and made builtin functions instead. It should only be necessary to implement read() and write() to get a file-like object having equal status with all others. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for "property" violates "Python is not a one pass compiler"
Phillip J. Eby wrote: > I'm not sure where you got the "Python is not a one pass compiler" idea; I > don't recall having seen this meme anywhere before, and I don't see how > it's meaningful anyway. Indeed, Python's bytecode compiler essentially *is* a one-pass compiler (or at least it used to be -- not sure what's been done to it recently). But the behaviour seen here is more about what happens at run time than compile time. What you're trying to do is essentially the same as print x x = 42 which fails at run time because x hasn't been bound when the print statement is executed. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug in urlparse
[EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]:
> According to RFC 2396[1] section 5.2:
>
> g) If the resulting buffer string still begins with one or more
> complete path segments of "..", then the reference is
> considered to be in error. Implementations may handle this
> error by retaining these components in the resolved path (i.e.,
> treating them as part of the final URI), by removing them from
> the resolved path (i.e., discarding relative levels above the
> root), or by avoiding traversal of the reference.
>
> If I read this right, it explicitly allows the urlparse.urljoin behavior
> ("handle this error by retaining these components in the resolved path").
>
Yes, the urljoin behaviour is explicitly allowed, however it is not the
most commonly implemented permitted behaviour. Both IE and Mozilla/Firefox
handle this error by stripping the spurious .. elements from the front of
the path. Apache, and I hope other web servers, work by the third permitted
method, i.e. rejecting requests to these invalid urls.
The net effect of this is that on some sites using a Python spider (e.g.
webchecker.py) will produce a large number of error messages for links
which browsers will actually resolve successfully. (At least that's when I
first noticed this particular problem). Depending on your reasons for
spidering a site this can be either a good thing or an annoyance.
___
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 Tue, 2005-09-06 at 00:56, Guido van Rossum wrote:
> On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > Eliminating the newline argument from print() would reduce the number of
> > reserved keyword arguments in my strawman by half. Maybe we could even
> > rename 'to' to '__to__' (!) to eliminate the other namespace wart. Is
> > this really too horrible:
> >
> > print('$user forgot to frobnicate the $file!\n',
> > user=username, file=file.name, __to__=sys.stderr)
>
> Yes, it is too horrible. As I said in another post, __xyzzy__ screams
> "special internal use, don't mess with this".
Fair enough -- it looked pretty icky to me too.
> I don't think the namespace wart is really a problem though; it's
> simple enough *not* to use 'to' as a variable name in the format.
True.
> Didn't you mean printf()? (Though I think if the format string doesn't
> roughly follow C's format string conventions the function shouldn't be
> called printf().)
Yep, I meant printf().
> What do you think of the trick (that I wasn't aware of before) used in
> Java and .net of putting an optional position specifier in the format,
> and using positional arguments? It would be a little less verbose and
> with sensible defaults wouldn't quite punish everybody as much for the
> needs of i18n. Formats with more than 3 or 4 variables should be rare
> in any case (these are not the days of Fortran formatted output).
It's definitely an interesting idea, and would solve the namespace thing
too. The above /might/ look like (warning: pre-coffee thought follows):
printf('$1 forgot to frobnicate the $2!\n', username, file.name,
to=sys.stderr)
While that's a little less self-descriptive for a translator to deal
with (who would only see the string, not the call site), it certainly
looks nicer for a non-i18n application, and could certainly work for an
i18n app too. It's a neat idea worth exploring.
Also, I think you posted in a separate article a syntactic proposal for
including detailed formating in $-vars. ${varname:fmt} where 'varname'
could be an identifier a la PEP 292 or possibly a positional argument.
-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] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Greg Ewing wrote: >> (you completely missed the point -- today's print mechanism works on *any* >> object >> that implements a "write" method, no just file objects. saying that "oh, >> all you need is >> to add a method" or "here's a nice mixin" doesn't give you a print >> replacement) > > While we're on the subject, in Py3k I'd like to see > readline(), readlines(), etc. removed from file objects > and made builtin functions instead. It should only > be necessary to implement read() and write() to get > a file-like object having equal status with all > others. maybe some variation of http://www.python.org/peps/pep-0246.html combined with "default adapters" could come in handy here ? ___ 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] Example for "property" violates "Python is not a one pass compiler"
Greg Ewing wrote: > Indeed, Python's bytecode compiler essentially *is* > a one-pass compiler for a suitable setting of the "look-ahead window size", at least. some Python constructs cannot be compiled by a truly minimalistic one-pass compiler. ___ 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] bug in urlparse
Hi Duncan, On Tue, Sep 06, 2005 at 12:51:24PM +0100, Duncan Booth wrote: > The net effect of this is that on some sites using a Python spider (e.g. > webchecker.py) will produce a large number of error messages for links > which browsers will actually resolve successfully. As far as I'm concerned, even if it is not theoretically a buggy behavior, a proposed patch with the above motivation would be welcome (and, of course, this patch wouldn't break the RFC either). Armin ___ 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: > Greg> If a Python function is clearly wrapping a C function, one doesn't > Greg> expect to be able to pass strings with embedded NULs to it. > > Isn't that just floating an implementation detail up to the programmer (who > may > well not be POSIX- or Unix-aware)? Yes, but in some cases that's unavoidable. It would be impractical to provide embedded-NUL-capable replacements for all C functions that someone might want (and flat-out impossible for some, e.g. os.open()). Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
On 9/6/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Greg Ewing wrote: > > While we're on the subject, in Py3k I'd like to see > > readline(), readlines(), etc. removed from file objects > > and made builtin functions instead. It should only > > be necessary to implement read() and write() to get > > a file-like object having equal status with all > > others. > > maybe some variation of > >http://www.python.org/peps/pep-0246.html > > combined with "default adapters" could come in handy here ? That sounds like a good idea. I'm certainly getting concerned about the proliferation of methods that people "should" add to file-like objects, where read/write are the only fundamental ones needed. I can't see mixins working, as too many file-like objects are written in C... 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] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Fredrik Lundh wrote: > maybe some variation of > > http://www.python.org/peps/pep-0246.html > > combined with "default adapters" could come in handy here ? I really hope we can get by with something much less heavyweight than that. I'm far from convinced that something like PEP 246 proposes is necessary or desirable. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > So let's call it the "Swiss Army Knife > (...Not)" API design pattern. Aha! Maybe this is the long-lost 20th principle from the Zen of Python? Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
> That sounds like a good idea. I'm certainly getting concerned about
> the proliferation of methods that people "should" add to file-like
> objects, where read/write are the only fundamental ones needed.
>
> I can't see mixins working, as too many file-like objects are written in C...
One could use "class decorators". For example if you want to define the
method foo() in a file-like class, you could use code like:
def FooExtender(cls):
class wrapper(cls):
pass
try:
# Don't do anything if "foo" already defined
wrapper.foo
except AttributeError:
def foo(self):
""" Automatically generated foo method. """
self.write("foo\n")
wrapper.foo = foo
return wrapper
MyFileClass = FooExtender(MyCFileClass)
This is for classes, but the construct can be adapted to work on objects
instead.
The advantage of using a decorator-like function is that you can do some
complex processing in the function (you could for example automatically
define __ne__ if only __eq__ is defined, and conversely). And it could
probably plug, as an useful convenience or even an automatic mechanism,
into a more sophisticated adaptor system.
___
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
Greg Ewing wrote: > Guido van Rossum wrote: > >>So let's call it the "Swiss Army Knife >>(...Not)" API design pattern. > > > Aha! Maybe this is the long-lost 20th principle from > the Zen of Python? It also sounds like one of the reasons why the ultimates in programming swiss army knives (that is, Lisp macros and Ruby blocks) are unlikely to make an appearance in Python in their full, unconstrained 'glory'. . . There's an interesting comparison with UI design though - having a couple of different tools in the interface with sensible default behaviour is generally easier to use than a single tool where you have to tell it which behaviour you want all the time (or pick one as the default, and have to remember to tell the application when you want the other behaviour). 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
[Python-Dev] string.Template format enhancements (Re: Replacement for print in Python 3.0)
[EMAIL PROTECTED] wrote:
> Positional arguments remove too much meaning from the template.
>
> Compare:
>
> '$user forgot to frobnicate the $file!\n'
>
> with
>
> '$1 forgot to frobnicate the $2!\n'
>
> Whenever the template definition and its use are not directly
> adjacent, the template is that much harder to understand (i.e.,
> in the context of translation, one wouldn't see the arguments
> passed to the template).
Ideas like this one are really about taking the current C-originated string
formatting and replacing it with a more powerful version of the new
string.Template formatting.
One interesting idea to consider is to add "format" and "safe_format" string
methods (or "substitute" and "safe_substitute" if matching the PEP 292 method
names is considered important) which work something like:
# These would be new str and unicode methods
def format(*args, **kwds):
return string.Template(args[0]).substitute(*args[1:], **kwds)
def safe_format(*args, **kwds):
return string.Template(args[0]).safe_substitute(*args[1:], **kwds)
Then enhance string.Template such that:
1. Item identifiers could be numbers as well as valid Python identifiers
2. Positional arguments were added to the dictionary of items using their
argument index as a string
Something like:
# This would be modified behaviour of the substitute method
# rather than a separate method or function
def pos_substitute(*args, **kwds):
self = args[0]
kwds.update((str(idx), arg) for idx, arg in enumerate(args))
# Avoiding including self in kwds is also an option
return self.substitute(**kwds)
(To try this on Py2.4, use "$p1" for the positional arguments to easily get
around the restriction in the string.Template regex)
With the above changes, the following would work:
"$1: $2".format("Number of bees", "0.5")
And produce:
"Number of bees: 0.5"
When pre-compiling string.Templates, the keyword method is significantly
clearer, but if the syntax was accessible through a string method, then being
able to use positional arguments would be very handy.
At this point, the only thing missing is the ability to handle proper output
formatting - that would need to be done by invoking the string mod operator
directly on the positional argument via:
"$1: $2".format("Number of bees: ", "%0.2f" % val)
In theory (I haven't really tried this bit), it should be possible to adjust
string.Template to support the following equivalent:
"$1: $[0.2f]2".format("Number of bees: ", val)
That way, rather than inventing a new formatting language, string.Template
could leverage the existing string mod operator by substituting the result of
"('%' + fmt) % val" wherever it sees "$[fmt]name" or "$[fmt]{name}"
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] Replacement for print in Python 3.0
On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Positional arguments remove too much meaning from the template. > > Compare: > > '$user forgot to frobnicate the $file!\n' > > with > > '$1 forgot to frobnicate the $2!\n' > > Whenever the template definition and its use are not directly > adjacent, the template is that much harder to understand (i.e., > in the context of translation, one wouldn't see the arguments > passed to the template). The operative word being *whenever*. You're thinking of the i18n use case, where the format string is separated from the arguments. I'm thinking of the non-i18n use case, where the format isalmost always a string *literal* adjacent to the arguments. I'm not at all convinced that we should attempt to find a solution that handles both use cases; most Python code never needs i18n. -- --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] string.Template format enhancements (Re: Replacement for print in Python 3.0)
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> With the above changes, the following would work:
>"$1: $2".format("Number of bees", "0.5")
> And produce:
>"Number of bees: 0.5"
>
> When pre-compiling string.Templates, the keyword method is
> significantly clearer, but if the syntax was accessible through a
> string method, then being able to use positional arguments would
> be very handy.
As long as named arguments don't get lost, that's fine. I
often use templates stored in variables/passed around as
arguments, where the positional form is not clear at all:
template.format("Number of bees", "0.5")
--
Christian Tanzerhttp://www.c-tanzer.at/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I did a fair bit of tinkering with that on the weekend. Printing a sequence of
> strings is fine - it's the call to "map(str, seq)" that makes printing a
> sequence of non-strings uglier than it should be. Doing it that way also
> breaks the Python idiom of letting unicode remain as unicode.
Only of you insist on doing it in a single call. With an explicit for
loop all is well.
> However, one thing I eventually remembered was a discussion about a year ago
> regarding the possibility of allowing str.join and unicode.join to accept
> non-strings [1].
>
> That discussion ended up leaving the join methods alone, because it is damn
> hard to do it without slowing down the common case where the sequence is all
> strings.
>
> I'm currently considering proposing a "joinany" method for str and unicode
> which accepts a sequence of arbitrary objects (I have a patch, but it needs
> unit tests and docs, and I'm uncomfortable with the amount of code duplication
> between the join and joinany methods).
Why not take an idea that Fredrik Lundh mentioned earlier, and have a
built-in *function* named join() which takes a sequence and a string?
joinany() is an ugly name.
But what's still missing is a use case analysis where you prove that
the use case is common enough to require explicit support.
> This becomes especially clear once "sorted" and "list.sort" are given as
> examples where the various keyword arguments do not change the basic invariant
> properties of the sorting operations - you start with a sequence, and you end
> up with essentially the same sequence, only in a different order. The keyword
> arguments simply control the precise meaning of "different order".
Thanks -- a very good example!
> 'printraw' is good - it makes it clear it is part of the same family as
> 'print' and 'printf', and explains succintly how it differs from the normal
> print function.
(Except that 'raw' could mean anything.)
> Additionally, doing 'printraw' with 'printf' is a little tricky - the best
> I've come up with is "printf('%s'*3, a, b, c)".
Yeah, but often the real code you need to do is already written as
print("x =", x, "y =", y, "z =", z)
and that becomes more readable when you transform it to
printf("x = %s y = %s z = %s\n", x, y, z)
--
--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 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> printf('$1 forgot to frobnicate the $2!\n', username, file.name,
>to=sys.stderr)
>
> While that's a little less self-descriptive for a translator to deal
> with (who would only see the string, not the call site), it certainly
> looks nicer for a non-i18n application, and could certainly work for an
> i18n app too. It's a neat idea worth exploring.
Is it worth doing this and completely dropping the %-based formats in
Py3k? (Just asking -- it might be if we can get people to get over the
shock of $ becoming first class ;-).
> Also, I think you posted in a separate article a syntactic proposal for
> including detailed formating in $-vars. ${varname:fmt} where 'varname'
> could be an identifier a la PEP 292 or possibly a positional argument.
+1
I proposed ${varname%fmt} earlier but it prevents you to extend the
varname syntax to arbitrary expressions, which I think is an extension
that will get lots of requests.
--
--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] Example for "property" violates "Python is not a one pass compiler"
Greg Ewing wrote: > Phillip J. Eby wrote: > >>I'm not sure where you got the "Python is not a one pass compiler" idea; I >>don't recall having seen this meme anywhere before, and I don't see how >>it's meaningful anyway. > > > Indeed, Python's bytecode compiler essentially *is* > a one-pass compiler (or at least it used to be -- not > sure what's been done to it recently). It builds the symbol table before actually trying to compile anything. This is what allows it to figure out which load commands to use for which symbols. I'm not up to speed on my compiler theory though, so I'm not sure if building the symbol table first is enough to count as two-pass compilation. > But the behaviour seen here is more about what happens > at run time than compile time. What you're trying to > do is essentially the same as > > print x > x = 42 > > which fails at run time because x hasn't been bound > when the print statement is executed. I've found this to be one of the subtler habits to try and break when coming from a static language - in something like C++, functions and classes are interpreted at compile time, and the result made part of the executable. In Python, the only thing created at compile time is the bytecode required to create the class or function - the definition isn't actually processed until runtime. It's easy to forget that difference (mainly because it doesn't matter very often). 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] Replacement for print in Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> wrote : > On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Whenever the template definition and its use are not directly > > adjacent, the template is that much harder to understand (i.e., This `i.e.` should have read `e.g.` :-( > > in the context of translation, one wouldn't see the arguments > > passed to the template). > > The operative word being *whenever*. You're thinking of the i18n use > case, where the format string is separated from the arguments. I'm > thinking of the non-i18n use case, where the format isalmost always a > string *literal* adjacent to the arguments. I'm not at all convinced > that we should attempt to find a solution that handles both use cases; > most Python code never needs i18n. I often put format strings into class variables (to be overriden) or pass them around as arguments, which has nothing to do with i18n. And i18n is going to be more and more important (says this german speaker who always tries to get away with English programs :-) I'm all for allowing positional arguments but would badly miss named arguments. -- Christian Tanzerhttp://www.c-tanzer.at/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
(just my 2 cents)
Le mardi 06 septembre 2005 à 07:23 -0700, Guido van Rossum a écrit :
> On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > printf('$1 forgot to frobnicate the $2!\n', username, file.name,
> >to=sys.stderr)
> Is it worth doing this and completely dropping the %-based formats in
> Py3k? (Just asking -- it might be if we can get people to get over the
> shock of $ becoming first class ;-).
For me, the problem with that proposal is not the precise format syntax,
but the fact that formatting is tied to a specific function which _also_
outputs stuff to screen.
There are really use cases where you want formatting without using a
"print" function in conjunction. Web pages, sending notification
e-mails, changing labels in GUI apps... anything that talks to the user
in a different way than using stdout.
IMO, printing and formatting must be distinct (*). And formatting should
be convenient and i18n-friendly (i18n is more and more important in
today's apps).
(*) they should be treated separately in the discussion, anyway
Regards
Antoine.
___
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 <[EMAIL PROTECTED]> wrote: [...] > OK, still with me? This, together with the observation that the only > use cases for the delimiter are space and no space, suggests that we > should have separate printing APIs for each of the use cases (a), (b) > and (c) above, rather than trying to fold (b) into (a) using a way to > parameterize the separator (and the trailing newline, to which the > same argument applies). For example: > > (a) print(...) > (b) printraw(...) or printbare(...) > (c) printf(fmt, ...) > > Each can take a keyword parameter to specify a different stream than > sys.stdout; but no other options are needed. The names for (a) and (c) > are pretty much fixed by convention (and by the clamoring when I > proposed write() :-). I'm not so sure about the best name for (b), but > I think picking the right name is important. Applying the same reasoning as above, why not remove the last remaining keyword parameter by adding fprint(ftobj,...) fprintraw( ftobj,...) and fprintf(ftobj,fmt,...) functions? -- rzed ___ 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] reference counting in Py3K
On 9/6/05, Nick Jacobson <[EMAIL PROTECTED]> wrote: > While we're on the subject of Python 3000, what's the > chance that reference counting when calling C > functions from Python will go away? We'd have to completely change the implementation. We're not planning on that. > To me this is one of the few annoyances I have with > Python. I know that Ruby somehow gets around the need > for ref. counting. You could always use IronPython or Jython of course, neither of which has 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
Re: [Python-Dev] String views
Greg> If a Python function is clearly wrapping a C function, one doesn't Greg> expect to be able to pass strings with embedded NULs to it. Skip> Isn't that just floating an implementation detail up to the Skip> programmer (who may well not be POSIX- or Unix-aware)? Fredrik> so if POSIX refuses to deal with, e.g., NUL bytes in file Fredrik> names, Python should somehow work around that to avoid Fredrik> "exposing implementation details" ? I don't know what the correct answer is. I suspect the right thing to do will vary depending on what C function is being wrapped. I was just making sure I understood correctly that there is a potential problem. 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
Guido van Rossum <[EMAIL PROTECTED]> writes: > On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: >> So here's the summary of the arguments against: two style points >> (trailing comma and >>stream) (from the man who approved the current >> decorator syntax!), and it's hard to extend. (By the way, I agree that >> the ">>" syntax is ugly, and IMO a bad idea in general. Shame the "@" >> wasn't used instead. :-) >> >> Seems pretty weak to me. Are there other args against? > > Sure. I made the mistake of thinking that everybody knew them. [...] > But more important to me are my own experiences exploring the > boundaries of print. [...] Gnyagh, couldn't you have *started* the thread with that post? :) Cheers, mwh -- Get out your salt shakers folks, this one's going to take more than one grain. -- Ator in an Ars Technica news item ___ 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/6/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Gnyagh, couldn't you have *started* the thread with that post? :) I hadn't anticipated so many great minds rusted shut. :-) -- --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 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > > printf('$1 forgot to frobnicate the $2!\n', username, file.name,
> > >to=sys.stderr)
...
> For me, the problem with that proposal is not the precise format syntax,
> but the fact that formatting is tied to a specific function which _also_
> outputs stuff to screen.
So borrow a trick from Common Lisp and use a destination of None
to mean "return the formatted text as a string".
>>> x = printf("$2 $1", 123,321)
321 123
>>> print x
None
>>> x = printf("$2 $1", 123,321, to=None)
>>> print x
321 123
Or is that too cryptic?
--
g
___
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/6/05, Gareth McCaughan <[EMAIL PROTECTED]> wrote: > So borrow a trick from Common Lisp and use a destination of None > to mean "return the formatted text as a string". [...] > Or is that too cryptic? Yes. To my mind, formatting (returning a string) and output are separate operations. A "write formatted output" operation is a useful convenience method, but it's not the basic operation. 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
Nick Coghlan wrote: > Greg Ewing wrote: > >>Guido van Rossum wrote: >> >> >>>So let's call it the "Swiss Army Knife >>>(...Not)" API design pattern. >> >> >>Aha! Maybe this is the long-lost 20th principle from >>the Zen of Python? > > > It also sounds like one of the reasons why the ultimates in programming swiss > army knives (that is, Lisp macros and Ruby blocks) are unlikely to make an > appearance in Python in their full, unconstrained 'glory'. . . In the context of my proposal it seems to imply some variation of Einsteins famous sentence: "Make everything as general as possible but not more general" or "Make everything as powerfull as possible but not more powerfull". The measure of possibility in this context may be serious community requirements. That's why I might have the impression that the language doesn't get any *deeper* but it is still very close to my actual work and highly usable. On the other hand I have to admit that I'm not really glad about 3 functions in favour for one statement. Introducing of a Writer object is just a different way of factoring and handling special cases and defaults. But I don't believe in an absolute truth about that. I'm not an OO stalinist. > There's an interesting comparison with UI design though - having a couple of > different tools in the interface with sensible default behaviour is generally > easier to use than a single tool where you have to tell it which behaviour > you > want all the time (or pick one as the default, and have to remember to tell > the application when you want the other behaviour). Hmm.. Guido cited strip, rstrip and lstrip for a good factoring into different functions. To me this is a limit case. It can become annoying soon and an API design antipattern. May I remember about C's vprintf, vfprintf, vsprintf, vsnprintf or the beauty of execl, execle, execlp, execlpe, execv, execve, execvp, execvpe? That's so grotesque that I feel deeply connected to Xah Lees crusade against UNIX in sudden moments ;) Kay ___ 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
putting on my "on the other hand" hat for a moment...
:::
Guido van Rossum wrote:
> 1. It's always been there
> 2. We don't want to type parentheses
> 3. We use it a lot
> 4. We don't want to change our code
there's also:
5. A reserved word makes it easy to grep for (e.g. to weed out
debugging prints before release).
6. It does the right thing under the hood: converts things to their
string representation, calls write repeatedly instead of allocating
a buffer large enough to hold all components, doesn't print un-
necessary trailing spaces, etc.
7. Using a statement syntax makes it possible to use a readable
syntax for redirection (and other possible extensions); it's obvious
that this isn't printing to stdout:
print >>file, bacon(ham), spam, "=", eggs(number=count)
while
print(bacon(ham), spam, "=", eggs(number=count), to=file)
is a lot harder to parse, especially if you add more elements and
print lines (how fast can you answer the question "do all these
redirect to the same place" ?).
8. It can print to anything that implements a "write" method, no
matter what it is or what other methods it implements.
(etc)
:::
and my "on the other hand" gloves...
> - I quite often come to a point in the evolution of a program where I
> need to change all print statements into logging calls, or calls into
> some other I/O or UI library.
never happens to me -- in my experience, good logging requires
some basic design up front, so you might as well log via functions
right from the start. print is reserved for debugging, tracing during
development, and console-oriented scripts. I cannot recall ever
having converted one of the latter to a component that needed
logging.
> - Having special syntax puts up a much larger barrier for evolution of
> a feature.
on the other hand, having special syntax gives you a lot more flexibility
in coming up with readable, grokkable solutions. not everything fits into
the callable paren list of comma separated stuff some of it with equal
signs in it end paren pattern.
> - There is a distinct non-linearity in print's ease of use once you
> decide that you don't want to have spaces between items
in practice, % is a great way to deal with this.
> - If it were a function, it would be much easier to replace it within
> one module (just def print(*args):...) or even throughout a program
> (e.g. by putting a different function in __builtin__.print).
if that's an important feature, what keeps us from adding a hook
(along the lines of __import__) ?
one could even argue that making it easier to override it locally
may make it harder to override it globally; consider this local
override:
def print(fmt, *args):
sys.stdout.write("MY MODULE SAYS " + fmt % args)
print("blabla")
with this in place, changing __builtin__.print will override everything
except the prints in "MY MODULE"... so you end up doing a stdout
redirect, just as in today's python.
(etc)
:::
___
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
Kay Schluehr wrote: > In the context of my proposal it seems to imply some variation of > Einsteins famous sentence: "Make everything as general as possible but > not more general" or "Make everything as powerfull as possible but not > more powerfull". I prefer McGrath's variation: "Things should be as complex as necessary but not more complex." ___ 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
[Barry Warsaw wrote]
> Also, we already have precedence in format+print in the logging
> package. I actually think the logging provides a nice, fairly to use
> interface that print-ng can be modeled on.
The main reason for doing that in the logging package is for
performance: processing the args into the format string can be deferred
until the logging system knows that the log message will actually be
used. I'm not saying that the separation of 'fmt' and args in the
logging methods doesn't have the other benefit of clarity:
log.debug("%s %s %s %s ...", arg1, arg2, arg3,
really_really_long_arg4,) # nicer
log.debug("%s %s %s %s ..." % (arg1, arg2, arg3,
really_really_long_arg4)) # icky
but the performance reason doesn't apply to the printf()/write()
discussion here.
Trent
--
Trent Mick
[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
Please bear with me if this has already been stated, or if I ought to be directing this to the wiki instead of to python-dev at this point. I've been trying to follow this whole discussion but have only gotten as far as last Saturday. Two things: First of all, I wanted to encourage Guido. There have been lots of people objecting to "fixing" the print statement, but I for one agree that it's a wart which should be addressed if it can be done elegantly. I'm just not speaking up because others (particularly Guido) have already said most of what I am thinking and I don't want to clutter the discussion with "me too!"'s. And one thing which (as far as I've read) _IS_ a new suggestion. I agree that a new built-in function ought to be named 'print'. This poses problems for those who want to write code NOW that runs in Python 2.x (for large values of x) which will also run in 3.0. We could satisfy both people if in Python 2.x we introduced a built-in function named "print30" (for Python 3.0) with the intended new behavior. People could start coding now using the "print30" builtin. When Python 3.0 was released, 'print' would no longer be a keyword, and both 'print' and 'print30' would be built-ins that both refered to the same function. Sure, it's a tiny bit of backward compatibility cruft to have a second name for the builtin, but it may be worth it because the ability to write in the "Python 3.0 style" (all new-style classes, only raise proper exceptions, etc) in the 2.x series is a VERY useful feature. We want to handle the transition better than Perl. -- 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] Hacking print (was: Replacement for print in Python3.0)
Bill Hanssen writes: > I think the "-ln" > variants made familiar by Pascal and Java were a bad idea, on a par > with the notion of a split between "text" and "binary" file opens. It's a bit off topic, but it wasn't the languages that introduced the difference between "text" and "binary" files. Pascal defined a difference between "text" and "record" files because the operating systems of the time had two distinct file types. Java initially had only one type (binary files which got automagically converted to a stream of unicode characters) and later modified things to allow manual control of the encoding because "modern" operating systems (like Windows) have two distinct file types. Don't blame the language designers, blame the OS folks. -- 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] reference counting in Py3K
Nick Jacobson wrote: > While we're on the subject of Python 3000, what's the > chance that reference counting when calling C > functions from Python will go away? > > To me this is one of the few annoyances I have with > Python. I know that Ruby somehow gets around the need > for ref. counting. > Reference counting is an implementation detail, and isn't a part of the language specifications. I have no idea why you find it so annoying, but there are other implementations (Jython, Iron Python) that don't use it. 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] reference counting in Py3K
On Sep 6, 2005, at 12:13 PM, Steve Holden wrote: > Nick Jacobson wrote: > >> While we're on the subject of Python 3000, what's the >> chance that reference counting when calling C >> functions from Python will go away? >> >> To me this is one of the few annoyances I have with >> Python. I know that Ruby somehow gets around the need >> for ref. counting. >> >> > Reference counting is an implementation detail, and isn't a part of > the > language specifications. I have no idea why you find it so > annoying, but > there are other implementations (Jython, Iron Python) that don't > use it. Personally I've found that reference counting makes Python really easy to integrate with other systems that may or may not also use reference counting. It is somewhat of a chore to incref/decref all over the place, but you *are* programming in C. -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, I think this is a very nice summary of the arguments for removing print. Let's change the link in PEP 3000 to point to this message. 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] Hacking print (was: Replacement for print in Python3.0)
Sorry to be confusing. I hadn't meant to imply that the split between text and binary files were somehow the fault of any programming languages, just the split between "write" and "writeln". Equally bad ideas with different origins. Though I continue to believe that Python should default to opening a file as "binary", not "text", and that the current default is a defect in Python. Bill > Bill Hanssen writes: > > I think the "-ln" > > variants made familiar by Pascal and Java were a bad idea, on a par > > with the notion of a split between "text" and "binary" file opens. > > It's a bit off topic, but it wasn't the languages that introduced the > difference between "text" and "binary" files. Pascal defined a difference > between "text" and "record" files because the operating systems of the > time had two distinct file types. Java initially had only one type > (binary files which got automagically converted to a stream of unicode > characters) and later modified things to allow manual control of the > encoding because "modern" operating systems (like Windows) have two > distinct file types. > > Don't blame the language designers, blame the OS folks. > > -- 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/janssen%40parc.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
Guido van Rossum wrote:
> On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>>printf('$1 forgot to frobnicate the $2!\n', username, file.name,
>> to=sys.stderr)
>>
>>While that's a little less self-descriptive for a translator to deal
>>with (who would only see the string, not the call site), it certainly
>>looks nicer for a non-i18n application, and could certainly work for an
>>i18n app too. It's a neat idea worth exploring.
>
>
> Is it worth doing this and completely dropping the %-based formats in
> Py3k? (Just asking -- it might be if we can get people to get over the
> shock of $ becoming first class ;-).
>
>
>>Also, I think you posted in a separate article a syntactic proposal for
>>including detailed formating in $-vars. ${varname:fmt} where 'varname'
>>could be an identifier a la PEP 292 or possibly a positional argument.
>
>
> +1
>
> I proposed ${varname%fmt} earlier but it prevents you to extend the
> varname syntax to arbitrary expressions, which I think is an extension
> that will get lots of requests.
>
I would anticipate security issues with allowing general expressions:
you are effectively allowing access to eval(). If a naiive programmer
were to use unverified input as a format string unpleasant things could
happen ... your call, but it seems dangerous to me. Remember C's printf
has been the source of some very dangerous errors.
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] Simplify the file-like-object interface (Replacement for print in Python 3.0)
[Greg Ewing] > While we're on the subject, in Py3k I'd like to see > readline(), readlines(), etc. removed from file objects > and made builtin functions instead. It should only > be necessary to implement read() and write() to get > a file-like object having equal status with all > others. [Fredrik Lundh] > maybe some variation of > >http://www.python.org/peps/pep-0246.html > > combined with "default adapters" could come in handy here ? [Paul Moore] > That sounds like a good idea. I'm certainly getting concerned about > the proliferation of methods that people "should" add to file-like > objects, where read/write are the only fundamental ones needed. > > I can't see mixins working, as too many file-like objects are written in C... I'd also prefer something along the lines of Fredrik's suggestion, but I don't write enough C code to understand Paul's last point. Could someone briefly explain why mixins wouldn't work in C code? I scanned the Python/C API Reference Manual, but all I could find was that, for tp_base "only single inheritance is supported; multiple inheritance require dynamically creating a type object by calling the metatype."[1] [1] http://docs.python.org/api/type-structs.html#l2h-983 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
Michael Chermside wrote: > We could satisfy both people if in Python 2.x we introduced a > built-in function named "print30" (for Python 3.0) with the intended > new behavior. People could start coding now using the "print30" > builtin. When Python 3.0 was released, 'print' would no longer be > a keyword, and both 'print' and 'print30' would be built-ins that > both refered to the same function. -1000 It's ugly, and it doesn't help the transition whatsoever IMO. We *definitely* don't want a print30 function hanging around in Python 3.0 for backwards compatibility with the miniscule number of people who used it in Python 2.x. The simplest solution is (as already stated):: from __future__ import __print_function__ Tim Delaney ___ 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
> LOL! That's a great solution for the 5 of us dinosaurs still using the > One True Editor. :) And who also still program in C now and then :-). I think there are more than 5 of us, though. 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] string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
> Some languages have "picture" formats, where the structure > of the format string more closely mimics that of the desired > output. (This is true, e.g., of some Basics and of one variety > of Perl output.) The trouble with this is that it limits how > much information you can provide about *how* each value is > to be formatted within the available space. COBOL! From the snippet Steven posted about C#, it seems to have a mode of "custom number formatting" which is picture-based. 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: > So let's call it the "Swiss Army Knife > (...Not)" API design pattern. IIRC, this is one of the design principles which inspired Lisp mixins. The idea was that different interfaces should be separated into different classes. If you needed a class which combined them, you'd just mix two superclasses together. 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
> In the end the process is not democratic. Which may make it easier: rather than having to convince 50%+ of the people, one only has to convince a single person... > I don't think there's anything that can change my mind > about dropping the statement. As long as "I don't think there's anything" isn't "There isn't anything", there is still hope, and the potential that the one person's opinion that matters can be changed. However, when I wrote the email, I assumed you wouldn't read it (because you said you were leaving the discussion until there was a PEP). What I wanted to know was what the best way of putting together succinct, clear, reasons why you should change your mind would be, so that could be done. Even if you didn't change your mind, at least it would be (judging from previous decision reversals) the best shot. =Tony.Meyer ___ 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 core documentation
Hi! I sent this to Fred Drake a few weeks ago but got no response. I assume he's busy, or maybe my message never reached him. I hope some of you will have opinions on this (BTW, please Cc: me on any replies, as I am not on python-dev). (Original message below) I was sharing some ideas with Gustavo Niemeyer (who's also receiving a copy of this message) and he told me you'd be the right person to talk to [he was also the one who recommended that I resent it to python-dev]. I'm relatively new to Python, my first project with it started at the beginning of 2004. And, from the start, its documentation bugged me a little. Now I'm completely hooked and am a full-time Python programmer, but I still see the same quirks in documentation. I don't mean to say there's lack of it, but I think it needs some work, it seems quite incomplete. I see some of these characteristics in the tutorial and module documentation, but I'm refering mostly to internal documentation. A simple example: >>> [].sort.__doc__ L.sort(cmpfunc=None) -- stable sort *IN PLACE*; cmpfunc(x, y) -> -1, 0, 1 While it may seem obvious to somewhat experiencied programmers, it should be explicit, at least for newbies, what "-1, 0, 1" means, in term of comparison (and also what happens if cmpfunc is left out - since it defaults to None, one could think no sorting takes place). But this is relatively minor, and not the best example. >>> [].remove.__doc__ L.remove(value) -- remove first occurrence of value What if L doesn't contain 'value', does it raise an exception or does it fail quietly? Does 'remove return anything (the new list, maybe)? >>> [].pop.__doc__ L.pop([index]) -> item -- remove and return item at index (default last) What if L is empty? I think you see what I'm getting at: there's a lack of standardization and completeness that can be frustrating, especially for those new to Python and to programming. When I came to Python, I was already a long-time C and Perl programmer, and I got around these things quite easily, mainly by testing at the prompt or sometimes reading source code, but, still, it doesn't seem like a very pythonic way of doing things (explicit better than implicit?). Not to mention clever editors, which could benefit from standard, complete documentation. There are even some modules with empty docstrings, which I think should be strictly forbidden in core modules. For instance: >>> thread.error.__doc__ >>> As I told Niemeyer, I considered sending documentation patches, but I think a standard should be defined first, and then volunteers (myself included) could sweep over the core language and conform documentation to it. I'm willing to work on it and help however I can, but I wanted to discuss it first (that's why I came to Niemeyer). Well, let me know what you think. Cheers, rbp -- Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG KeyId: <0x0DB14978> http://isnomore.net I'll rule you all with an iron fist! [...] You! Obey the fist! -- Invader Zim ___ 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 core documentation
On Tuesday 06 September 2005 16:26, Rodrigo Bernardo Pimentel wrote: > I sent this to Fred Drake a few weeks ago but got no response. I > assume he's busy, or maybe my message never reached him. I hope some of It did reach me, but feel into the black hole of "I can't deal with this in the next 5 minutes." Sorry. I do intend to read your message carefully and respond then. -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] Example for "property" violates "Python is not a one pass compiler"
Nick Coghlan wrote: > It builds the symbol table before actually trying to compile anything. This > is > what allows it to figure out which load commands to use for which symbols. Yes, nowadays I expect it makes two passes over the parse tree for each function, one to build the symbol table and one to generate the bytecode. It used to make a single pass over the parse tree and then post-process the bytecode once it had figured out which variables were local -- which I suppose you could call one-and-a-bit passes. :-) The distinction between one and two passes isn't so important in a dynamic language like Python anyway, since most of the interesting things happen at run time. -- 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 core documentation
On Tuesday 06 September 2005 16:26, Rodrigo Bernardo Pimentel wrote: > I sent this to Fred Drake a few weeks ago but got no response. I > assume he's busy, or maybe my message never reached him. I hope some of > you will have opinions on this (BTW, please Cc: me on any replies, as I am > not on python-dev). Again, I'm sorry I haven't had time to reply until now, but reminders/re-posts like this are certainly a welcome reminder! > (Original message below) > > I was sharing some ideas with Gustavo Niemeyer (who's also > receiving a copy of this message) and he told me you'd be the right person > to talk to [he was also the one who recommended that I resent it to > python-dev]. I'll suggest that the Documentation SIG is a better place to discuss this for some reasons, and I've CC'd that list as well. > I'm relatively new to Python, my first project with it started at > the beginning of 2004. And, from the start, its documentation bugged me a > little. Now I'm completely hooked and am a full-time Python programmer, > but I still see the same quirks in documentation. > > I don't mean to say there's lack of it, but I think it needs some > work, it seems quite incomplete. I see some of these characteristics in > the tutorial and module documentation, but I'm refering mostly to internal > documentation. It appears that by "internal" you're referring to the docstrings available from the runtime. I generally only think of those as hints or reminders, and not complete documentation (other minds disagree). For the non-docstring documentation, the same kinds of issues occur, though not always for the same features. I'd categorize the issues you point out into two groups: A) Omissions. You're right; there's a lot of places we haven't been as thorough as we should be. These certainly should be corrected by adding the missing information. B) Vague contracts. There are many places where documentation is omitted because the contracts of the documented feature aren't clearly specified by the code. This may happen for many reasons, but how each should be handled has to be determined on a case-by-case basis. In many cases, it's intentional that edge cases aren't well specified, simply because the treatment hasn't been discussed and decided. This case can usually be resolved by bringing up specific cases; once there's some discussion, useful documentation can be written because the documentation writers learn what the intent was (or the developers have to decide what the contract should be). Historically, I think we've seen a lot of (B) simply because there's an expectation of users will read the source to determine what the feature will do in any given case. As we see more implementations appear, and as the size and range of Python's audience grow, this becomes a less reasonable approach. This is especially the case for features implemented in C, since users are increasingly unlikely to have the C sources handy due to the use of pre-compiled packages on all platforms. [...lots of specific examples elided...] > As I told Niemeyer, I considered sending documentation patches, > but I think a standard should be defined first, and then volunteers > (myself included) could sweep over the core language and conform > documentation to it. I'm willing to work on it and help however I can, but > I wanted to discuss it first (that's why I came to Niemeyer). It would be good to have more specific guidelines for documentation. We've generally avoided trying to specify what exceptions can be raised by various functions or methods, and describe only specific cases that are guaranteed as part of the API. Treatment of edge cases is often left as an accident as well, though not as frequently. As the documentation increasingly becomes the way that programmers learn about the details of the library, we need to think about whether this is the right approach. In addition to this, we should settle the question of completeness of docstrings and document it. Anything missing that should be included according to that decision should then be added. Also, the level of detail regarding edge cases and exceptions that we're willing to make contract should be discussed, and documentation brought up to snuff. This is more likely an issue that will require case-by-case treatment. -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] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Steven Bethard wrote: > Could > someone briefly explain why mixins wouldn't work in C code? Depends on what you mean by "work in C code". It's only possible for a type object to inherit C struct members from one base class, since the struct has to be an extension of the base C struct. Dynamic attributes and methods can be inherited from multiple base classes, however, if you're willing to write the necessary C code to create the type object dynamically, as would happen if it were being defined with Python code. -- 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 formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
Bill Janssen wrote: > > someone wrote: > > > Some languages have "picture" formats, where the structure > > of the format string more closely mimics that of the desired > > output. > > COBOL! From the snippet Steven posted about C#, it seems to have a > mode of "custom number formatting" which is picture-based. A nice characteristic of a well-designed picture formatting system is that the pictures take up the same amount of space in the format string as the output they generate. So you can write things like headings = "Description Qty Price Amount" format = "AAA ###0 $#,##0.00 $#,###,##0.00" and visually check that the headings and columns will line up, without having to be concerned with the exact numbers of characters in each column. I think a picture-formatting function would be a nice thing to have as an alternative to %-formatting or whatever will replace it. And-then-we-can-call-it-PyBol-3000-ly, -- 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
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> I'm not at all convinced that we should attempt to find a Guido> solution that handles both use cases [print replacement Guido> and i18n]; most Python code never needs i18n. It's true that the majority of Python applications never need i18n, because they're only used in one language. But Python applications are mostly assembled from a large and growing set of Python-standard and other well-known libraries. It would be very useful to keep the barriers to i18n-ization as low as possible to make those libraries as broadly applicable as possible. You're talking about Python 3.0; I don't know if it can be done within a reasonable amount of effort (and if not, too bad), but in that planning horizon it is surely worth some effort to find a solution. -- 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] Replacement for print in Python 3.0
On 9/6/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > It's true that the majority of Python applications never need i18n, > because they're only used in one language. But Python applications > are mostly assembled from a large and growing set of Python-standard > and other well-known libraries. It would be very useful to keep the > barriers to i18n-ization as low as possible to make those libraries as > broadly applicable as possible. Sure, we must provide good i18n support. But the burden on users who don't need i18n should be negligeable; they shouldn't have to type or know extra stuff that only exists for the needs of i18n. The same is true for many other needs of library authors and programming-in-the-large: programming-in-the-small should come first and foremost. We don't need another J2EE. > You're talking about Python 3.0; I don't know if it can be done within > a reasonable amount of effort (and if not, too bad), but in that > planning horizon it is surely worth some effort to find a solution. There seem to be many people interested in finding this solution; I see it as my task (among others) to make sure that their solution doesn't negatively affect the life of the majority of users who don't need it. Even if there's a class of users who think they don't need it and in the end find they do. That's too bad, they will have to apply some global transformation to their code. I hope that making print a function will help make that transformation easier. I've seen a couple of responses claiming that with good planning there won't be a need for such transformation (and consequently they don't need the changes I'm proposing). Well duh! I've never had perfect foresight. If you always plan ahead for what you might need, you inevitably end up writing an overly heavy framework. Remember YAGNI! -- --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] reference counting in Py3K
Guido van Rossum wrote: >>While we're on the subject of Python 3000, what's the >>chance that reference counting when calling C >>functions from Python will go away? > > We'd have to completely change the implementation. We're not planning on that. Also, the refcounting would have to be replaced by something else that would also be fairly intrusive on the C interface, such as having to remember to make all your local variables known to the garbage collector. A better plan would be to build something akin to Pyrex into the scheme of things, so that all the refcount/GC issues are taken care of automatically. -- 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] reference counting in Py3K
On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > A better plan would be to build something akin to > Pyrex into the scheme of things, so that all the > refcount/GC issues are taken care of automatically. That sounds exciting. I have to admit that despite hearing many enthusiastic reviews, I've never used it myself -- in fact I've written very little C code in the last few years, and zero new extension modules. (Lots of Java, but that's another story. :-) I expect that many standard extensions could benefit from a rewrite in Pyrex, although this might take a lot of work and in some cases not necessarily result in better code (_tkinter comes to mind -- though I don't really know why this would be). So this shouldn't be the goal (yet). Instead, we should encourage folks to write *new* extensions using PyRex. How stable is Pyrex? Would you be willing to integrate it thoroughly with the Python source tree, to the point of contributing the code to the PSF? (Without giving up ownership or responsibility for its maintenance.) -- --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] reference counting in Py3K
Guido van Rossum wrote: > How stable is Pyrex? Would you be willing to integrate it thoroughly > with the Python source tree, to the point of contributing the code to > the PSF? (Without giving up ownership or responsibility for its > maintenance.) +100 I would be *strongly* in favour of this. Apart from anything else, it would greatly lower the bar for people wanting to add to the standard library. And if much of the stdlib were eventually rewritten in Pyrex it would be even better. Tim Delaney ___ 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] reference counting in Py3K
At 09:58 PM 9/6/2005 -0700, Guido van Rossum wrote: >On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > A better plan would be to build something akin to > > Pyrex into the scheme of things, so that all the > > refcount/GC issues are taken care of automatically. > >That sounds exciting. I have to admit that despite hearing many >enthusiastic reviews, I've never used it myself -- in fact I've >written very little C code in the last few years, and zero new >extension modules. (Lots of Java, but that's another story. :-) > >I expect that many standard extensions could benefit from a rewrite in >Pyrex, although this might take a lot of work and in some cases not >necessarily result in better code (_tkinter comes to mind -- though I >don't really know why this would be). So this shouldn't be the goal >(yet). Instead, we should encourage folks to write *new* extensions >using PyRex. Just an FYI; Pyrex certainly makes it relatively painless to write code that interfaces with C, but it doesn't do much for performance, and naively-written Pyrex code can actually be slower than carefully-optimized Python code. So, for existing modules that were written in C for performance reasons, Pyrex isn't currently a substitute. One of the reasons for this is that Pyrex code uses the generic Python/C APIs, like PySequence_GetItem, even in cases where PyList_GetItem or its macro form would be more appropriate. Pyrex has no way currently to say, "this is type X's C API, so use it when you have a variable that's of type X, instead of using the generic object protocols." There are other issues that contribute to the inefficiency as well, like redundant refcounting, assigning None to temporary variables, etc. I haven't used the absolute latest version of Pyrex, but older versions also used C strings for attribute lookups, which was horribly slow. I think the latest version now creates string objects at module initialization to avoid this issue, though. Anyway, don't get me wrong - Pyrex is by *far* my preferred way of writing C extensions for Python. And I'd love to see a version that used your proposed static typing syntax in place of the "cdef" syntax it currently uses, thus paving the way to selective translation of Python to C. I'd just like to set expectations appropriately, for what it is and isn't good at. Sadly, the current state of Pyrex is such that to write efficient code, you have to use the Python C API from Pyrex, which tends to result in something that looks like C code with Python-like syntax. But you don't have to worry about memory allocation, exception labels, or reference counting, so it's more compact and less error-prone than C too. ___ 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
