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 s
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 "principl
Guido van Rossum wrote:
> On 9/9/05, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
>>Any possibility to add one (or more) __future__ statement to
>>implicitly get this behavior? Any suggestion about naming?
>
>
> For the builtins, it would actually be possible to do this by simply
> importing an alt
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 ment
> 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/)
__
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
> -
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 PROTECTE
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: B
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(),
zip(
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (holger krekel) wrote:
> 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 spelle
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:
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 cur
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"?
> > Rememb
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 als
> 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 lib
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
Un
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!
Wel
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=detail&aid=1283895&group_id=5470&atid=105470
>
>T
[Brett Cannon]
> I assume that the Windows installer includes the Tools/ directory.
It installs part of it, not all:
C:\Python24\Tools>dir/b
i18n
pynche
Scripts
versioncheck
webchecker
So it's missing these Tools directories:
audiopy
bgen
compiler
faqwiz
framer
freeze
modulator
msi
unicode
worl
Antoine Pitrou:
> As for seamless unicode support, there are also problems sometimes with
> filenames and filepaths: see e.g.
> https://sourceforge.net/tracker/?func=detail&aid=1283895&group_id=5470&atid=105470
This bug report is using byte string arguments causing byte string
processing rathe
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
> i
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 cus
> 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,
Fredrik Lundh wrote:
> 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.
Not to mention the annoyingly large number of fonts that make '`' and ''' look
virtually identical :(
"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
___
25 matches
Mail list logo
