Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
IMO strings that are being printf'd can probably be assumed to
be human readable, and therefore candidates for translation.
This
Greg That's a dangerous assumption to make, I think.
Could be.
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Fredrik Lundh [EMAIL PROTECTED] writes:
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
Even more since they are especially broken in Windows XEmacs.
Thomas
This does make me think of the interesting prospect of an internationalised
string literal, though (e.g., _This an il8n string). I'm not sure it would
be enough of a win over the status quo though,
I don't think so either. i18n doesn't require its specific string
notation (in addition,
Antoine Pitrou wrote:
- seamless unicode support: how about making the default Python
charset utf-8 instead of ascii ? right now, someone (say an American or
English) who does not design his app with non-ascii characters in mind
may have a surprise when users enter those characters in
On Thu, Sep 08, 2005 at 06:52:59PM -0700, Brett Cannon wrote:
Otherwise it is mostly a lack of advertisement and them not being
installed by ``make install``. If you just download the soure and
Agreed. I've often wished that reindent.py was installed somewhere.
Probably the only way
is
[Brett Cannon]
I assume that the Windows installer includes the Tools/ directory.
It installs part of it, not all:
C:\Python24\Toolsdir/b
i18n
pynche
Scripts
versioncheck
webchecker
So it's missing these Tools directories:
audiopy
bgen
compiler
faqwiz
framer
freeze
modulator
msi
unicode
world
Le vendredi 09 septembre 2005 à 23:09 +1000, Neil Hodgson a écrit :
Antoine Pitrou:
As for seamless unicode support, there are also problems sometimes with
filenames and filepaths: see e.g.
https://sourceforge.net/tracker/?func=detailaid=1283895group_id=5470atid=105470
This bug
On 9/8/05, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
Could be. For me, the name print is associated with a long history
of magical behavior that only a human could possibly feel comfortable
with. One of the great sins of Pascal was tarring the name write
with the same brush!
Well, apart
Fredrik backquotes are a PITA to type on many non-US keyboards.
Interesting. On US keyboards they are often easier to type than parens...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
How should we document [the tools directory]
At the interactive prompt, help() lets me get a list
of topics (not including tools), keywords, or modules --
but no mention of tools.
I didn't find any references at http://python.org/doc/
The tutorial does mention the standard library (and
the
In article [EMAIL PROTECTED],
Tristan Seligmann [EMAIL PROTECTED] wrote:
* Lisandro Dalcin [EMAIL PROTECTED] [2005-09-08 13:56:07 -0300]:
Yes, you are right. But this way, you are making explicit a behavior
that will be implicit in the future.
For example, we could also do:
On Fri, Sep 09, 2005 at 11:31 -0700, Russell E. Owen wrote:
In article [EMAIL PROTECTED],
Tristan Seligmann [EMAIL PROTECTED] wrote:
Why does it matter if the single statement you insert is spelled
metaclass = type instead of from future import whatever?
Remember, unlike the
On 9/8/05, Antoine Pitrou [EMAIL PROTECTED] wrote:
Hi,
Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit :
It would be
nice to be able to lose the _() calls to gettext(). The function
would look to see if a message catalog was available for the current
output
Lisandro Dalcín proposes:
Any possibility to add something like
from __future__ import new_style_classes
Tristan Seligmann writes:
Why does it matter if the single statement you insert is spelled
metaclass = type instead of from future import whatever?
Russell Owen responds:
It
PEP 3000 says
(http://www.python.org/peps/pep-3000.html) :
Core language
- Return iterators instead of lists where appropriate for atomic type
methods (e.g. dict.keys(), dict.values(), dict.items(), etc.)
Built-in Namespace
- Make built-ins return an iterator where appropriate (e.g. range(),
Greetings,
I was wondering, why are we setting SIGPIPE to SIG_IGN
in initsigs():
static void
initsigs(void)
{
#ifdef SIGPIPE
PyOS_setsig(SIGPIPE, SIG_IGN);
#endif
[...]
}
One of the side effects is:
os.system(yes | read any)
yes: standard output:
Can you all just stop discussing this? In the last 4 contributions
nothing has been added that hasn't been said yet. It's not going to
change. Get used to it.There are more important issues.
On 9/9/05, Russell E. Owen [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED]
On 9/9/05, Lisandro Dalcin [EMAIL PROTECTED] wrote:
PEP 3000 says
(http://www.python.org/peps/pep-3000.html) :
Core language
- Return iterators instead of lists where appropriate for atomic type
methods (e.g. dict.keys(), dict.values(), dict.items(), etc.)
Built-in Namespace
- Make
I was wondering, why are we setting SIGPIPE to SIG_IGN
in initsigs():
Because you can get a SIGPIPE from writing to a socket whose other
side has shut down, and we want to turn that into an error.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Jim Jewett wrote:
How should we document [the tools directory]
At the interactive prompt, help() lets me get a list
of topics (not including tools), keywords, or modules --
but no mention of tools.
I didn't find any references at http://python.org/doc/
The tutorial does mention the
Antoine Pitrou:
I don't have a Windows machine at hand right now to test it, but, even
if this solution works, it breaks the principle of least astonishment:
Astonishment is subjective and so a poor tool to measure by. At one
stage Ruby tried to follow the more common formulation principle
If anyone would like to take a break from all this Py3k discussion, please
feel free to read through the following draft for the second August summary.
Checking over the O(N**2) behaviour in StreamReader.readline summary would
be particularly appreciated. As always, any corrections/suggestions
23 matches
Mail list logo
