Guido van Rossum [EMAIL PROTECTED] wrote:
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
[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
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.
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.)
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
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
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 --
[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
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
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
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.
/F
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
[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,
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
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
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
Python-Dev@python.org
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
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
[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
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
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
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
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
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
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
(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
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
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
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
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
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/)
___
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_
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
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
[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
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
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.
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
[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
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,
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
Python-Dev@python.org
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
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
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
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
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
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
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
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
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.
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
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
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.
53 matches
Mail list logo
