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
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. A
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 n
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
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 librari
> "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 appl
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
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 att
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
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
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
t
> 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 anythin
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 w
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
> 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*
> 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
http:/
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
[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.
[Fredr
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 si
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 open
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
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 t
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.
>
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. Pa
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 ha
[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
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 s
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
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 i
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 "writ
> > 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 whic
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/)
___
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
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> s
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 t
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
(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 f
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
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 co
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 nic
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 Pyth
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 accessi
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 dir
[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
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
> 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
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
http://mail.python.org/mail
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
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
[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)
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 concern
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.
_
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)
>
> Whi
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 elimi
[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 t
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 b
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'
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 w
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
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.
__
[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)?
61 matches
Mail list logo
