I don't use "print" myself much, but for the occasional 3-line script.
But I think the user-friendliness of it is a good point, and makes up
for the weirdness of it all. There's something nice about being able
to write
print "the answer is", 3*4+10
which is one of the reasons ABC and BASIC hav
> Providing you can live with adding a pair of parentheses to that, you can
> have:
>
>def print(*args):
> sys.stdout.write(' '.join(args) + '\n')
>
> I think the language would be cleaner if it lacked this weird exception for
> `print`.
Charles,
I agree that it would be cleaner. I j
> To me, the main objection seems to revolve around the fact that people would
> like to be able to "future-proof" Python 2.x code so that it will also run on
> Py3k.
Nick,
You seem to be dreaming. People like the "print" statement for many
and varied reasons, it seems. Skip's point about gra
Just to add a bit more perspective (though I continue to believe that
"print" should be retained as-is):
In my UpLib code, I no longer use print. Instead, I typically use a
variant of logging called "note" instead of print:
note ([LEVEL, ] FORMAT-STRING [, *ARGS])
It works just like C printf,
> I do hate having to write two parentheses -- it's more than the extra
> keystrokes. It's that I have to use two shifted characters and I have
> to be sure to close the construct, which can be a PITA when the start of
> the function call is separated from the end by many lines.
> What I found is
Guido writes:
> * Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
> the print statement (trailing comma, >>stream) are ugly, and because
> it's all syntax, other extensions are hard to make. Had it been a
> function from the start it would have been much easier to add keyword
> ar
Or perhaps:
>>> print [with FORMAT-STRING] [>> STREAM] *ARGS
as an alternative to
>>> printf [@ STREAM] FORMAT-STRING *ARGS
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
Steven,
> Did you see Nick Coghlan's post?
> http://mail.python.org/pipermail/python-dev/2005-September/056076.html
> I found his arguments to be reasonably compelling.
You were already convinced on Friday, so with you, he was preaching to
the choir. I'm not surprised you found those "argume
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
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
> 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:/
> 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*
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
> perhaps the Python 3 executable should have a different name as part
> of the standard distribution? I suggest "py" / "py.exe"
Perhaps the renaming should be more radical, to indicate the extent of
the change.
I suggest "second", to commemorate "Second City" in Chicago, another
famous comedy tr
> Perhaps the renaming should be more radical, to indicate the extent of
> the change.
Another possiblity would be to use the new name to indicate a position
in a spectrum of programming languages. For instance, "beryl",
"topaz", "steel" and "jade" are (on the Mohs scale) all sturdier than
pearl
> This [text/binary] distinction is
> supported by the basic file operations in the C library. To open a
> text file in binary mode is technically an error (although in many OSs
> you'll get away with it).
It's one of those "technical" errors that really isn't an error (from
Python). On the other
I agree with Skip.
Bill
> I suppose this is a dead horse now, but I will kick it one more time.
>
> Under the rubrics of "explicit is better than implicit" and "there should
> only be one wat to do it", I would rather see
>
> bool_val = bool(foo or bar)
>
> instead of having the "or" opera
> The best way to make people stop complaining about the GIL and start
> using
> process-based multiprogramming is to provide solid, standardized support
> for process-based multiprogramming.
And the model provided by the thread abstraction is a good API for that
support...
Bill
___
Sokolov Jura writes:
> It is so simple to write application server in Python.
> It is so difficult to make it scallable in CPython.
> CPython will not be wide popular without real multithreading.
He's right.
Bill
___
Python-Dev mailing list
Python-Dev@p
> 1) It works by default, so that novices can use it without falling
> into the deep well of threading. That is, a program that you write
> using threading is broken by default, and the tool you have to fix it
> is "inspection." I want something that allows me to say "this is a
> task. Go." and hav
> The problem with threads is at first glance they appear easy...
Anyone who thinks that a "glance" is enough to understand something is
too far gone to worry about. On the other hand, you might be
referring to a putative brokenness of the Python documentation on
Python threads. I'm not sure the
Skip,
> With the Mojam middleware stuff I suffered quite awhile with a
> single-threaded implementation that would hang the entire webserver if a
> backend query took too long. I realized I needed to do something (threads,
> asyncore, whatever), but didn't think I understood the issues well enoug
Guido writes:
> Given the tendency of Python developers to build layers of
> abstractions I don't think [non-preemptive threads] will help much.
I think that's right, although I think adding priorities to Python's
existing preemptive threads might be useful for real-time programmers
(yes, as machi
> >I'm thinking about making all character strings Unicode (possibly with
> >different internal representations a la NSString in Apple's Objective
> >C) and introduce a separate mutable bytes array data type. But I could
> >use some validation or feedback on this idea from actual
> >practitioners.
> Python should allow strings to
> contain any Unicode character and should be indexable yielding
> characters rather than half characters. Therefore Python strings
> should appear to be UTF-32.
+1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
> > - yet others think: "I want all of Unicode, with proper, efficient
> >indexing, so I want four bytes per char".
>
> I doubt the last one though. Probably they really don't want efficient
> indexing, they want to perform higher-level operations that currently
> are only possible using effic
Guido writes:
> Oh, I don't doubt that they want it. But often they don't *need* it,
> and the higher-level goal they are trying to accomplish can be dealt
> with better in a different way. (Sort of my response to people asking
> for static typing in Python as well. :-)
I suppose that's true. But
I think he was more interested in the invariant Martin proposed, that
len("\U0001")
should always be the same and should always be 1.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Might be more interesting to think about replacing ints and Decimal
with implicit-denominator rational type. In the HTTP-NG typing
proposal, we called this a "fixed-point" type. See Section 4.5.1 of
http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-frystyk-httpng-arch-00.txt
for details.
The cur
It's a shame that
1) there's no equivalent of "java -jar", i.e., "python -z FILE.ZIP", and
2) the use of zipfiles is so poorly documented.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
> This should work on a few platforms:
> env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
Yeah, that's not bad, but I hate setting PYTHONPATH. I was thinking
more along the line of
python -z ZIPFILE
where python would look at the ZIPFILE to see if there's a top-level
module called "__
Brett,
How about building a system that compiles a Python program (possibly
annotated) to an AJAX program? That is, it analyzes the program to
determine what's appropriate and possible for client-side and
server-side, figures out the optimal network API (reduce latency,
reduce calls, reduce data
Or the Web-SIG mailing list.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
The "data:" scheme would be a good one.
Bill
> Barry Warsaw wrote:
> > On Fri, 2006-01-20 at 21:43 +0100, Thomas Wouters wrote:
> >
> >> I don't believe this belongs in 2.4, since it can, actually, break code.
> >> Code that depends on the current situation, _TestCase__attributename.
> >> Fragil
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on an impossible quest.
+1.
This would remove my s
> what other reactive socket framework is there that would fit well into
> the standard library ? is twisted really simple enough ?
I've been very happy with Medusa, which is asyncore-based.
Perhaps the right idea is to fix the various problems of asyncore. We
might lift the similar code from t
Not terrible. I think I may try re-working Medusa to use this.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archi
501 - 537 of 537 matches
Mail list logo
