Hi
I often have the need for a generic object to use as the default value
for a function parameter, where 'None' is a valid value for the
parameter. For example:
_sentinel = object()
def first(iterable, default=_sentinel):
"""Return the first element of the iterable, otherwise th
On 5/22/07, Martin Blais <[EMAIL PROTECTED]> wrote:
>
> ReST works well only when there is little markup. Writing code
> documentation generally requires a lot of markup, you want to make
> variables, classes, functions, parameters, constants, etc.. (A better
> avenue IMH
On 5/22/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> > Don't get me wrong, LaTeX is a powerful tool and I use it for every bigger
> > document i type. I just think it's not the best choice for documenting
> > scripting
> > languages.
>
> Who's documenting a scripting language?
Hehe
I can't bel
On 5/22/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> So in Armin's example, I found the reST version *much* easier to read.
> Whether that difference in perception is due simply to my relative lack
> of experience in using LaTeX, or to something else, I have no idea.
- If you make a mistake in
On 5/22/07, Armin Ronacher <[EMAIL PROTECTED]> wrote:
> > >
> > > * reST markup isn't much simpler than LaTeX.
> >
> > * reST doesn't support nested markup, which is used in the current
> > documentation.
>
> For a lightweight markup language that is human readable (which rst certainly
> is) th
On 5/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Georg> There is exactly one instance of LaTeX math in the whole docs,
> Georg> it's in the description of audioop, AFAIR, an contains a sum over
> Georg> square roots...
>
> Georg> So, that's not really a concern of mine ;
On 5/20/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Very nice! As well as looking very attractive and professional, the
> all-Python
> > toolset should make it easier to build the documentation - I've not been
> > able to get a trouble-free setup of the docs toolchain on Windows.
>
> Yep. A
Hi Georg
Super impressive work! :-)
I haven't looked at it in depth yet, but I have a question. One
concern from a long thread on Doc-Sig a long time ago, is that ReST
did not at the time possess the ability to nicely markup the objects
as LaTeX macros do. Is your transformation losing markup i
In the subprocess module, by default the files handles in the child
are inherited from the parent. To ignore a child's output, I can use
the stdout or stderr options to send the output to a pipe::
p = Popen(command, stdout=PIPE, stderr=PIPE)
However, this is sensitive to the buffer deadlock p
ood idea to add this to the
builtins in the future?
(Implementation follows.)
=
#!/usr/bin/env python
"""
Inject some tracing builtins debugging purposes.
"""
__version__ = "$Revision: 1781 $"
__author__ = "Martin Blai
On 5/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/31/06, Martin Blais <[EMAIL PROTECTED]> wrote:
> > So I assume you're suggesting the following renames:
> >
> > pack_to -> packinto
> > recv_buf -> recvinto
> > recvfrom
Hi all
I'd like to know what the policy is on the source code indentation for
C code in the interpreter. At the Need-for-Speed sprints, there was
consensus that there is a "new" indentation for style for the Python C
source files, with
* indentation (emacs: c-basic-offset): 4 chars
* no tabs (so
On 5/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [python-checkins]
> > >> * Added socket.recv_buf() and socket.recvfrom_buf() methods, that
> > >> use the buffer
> > >> protocol (send and sendto already did).
> > >>
> > >> * Added struct.pack_to(), that is the corresponding buffer
> > >>
On 5/29/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> If it is really 0.5%, then we're fine. Just remember that PyStone is an
> amazingly uninformative and crappy benchmark.
I'm still looking for a benchmark that is not amazingly uninformative
and crappy. I've been looking around all day
estion I will write up a mini-PEP for
discussion of this idea and will move the code in the sandbox (and out
of a branch).
Additionally, I must say, all that hot water in the blue lagoon this
morning was a really hot justficiation for the "hot buffer" name.
http://furius.ca/tmp/nfs3/html/20
growing sleep-hours deficit. I
> hope you forgive me.
>
> Have a good day,
> Noam
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mail
On 4/7/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Apr 2006 10:07:26 -0400, Martin Blais wrote:
>
> > There are cases where you need N_() after initialization, so you need
> > both, really. See the link I sent to Alex earlier (to the GNU manual
> >
On 4/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Bob Ippolito wrote:
>
> > > Try the 2.5 alpha 1 just released, and you'll see that the toplevel
> > > package is now xml.etree. The module and class are still called
> > > ElementTree, though.
> >
> > It would be nice to have new code be PEP 8
On 4/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> >> P(a("Click here to forget", href="...
> >
> > No. That's not going to work: pygettext needs to be able to extract
> > the string for the catalogs.
On 4/7/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> > Hi all
> >
> > I got an evil idea for Python this morning -- Guido: no, it's not
> > about linked lists :-) -- , and I'd like to bounce it here. But
> > first, a bit of
On 4/7/06, Alexander Schremmer <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Apr 2006 20:35:51 -0400, Martin Blais wrote:
>
> > This is pretty standard
> > getttext stuff, if you used _() a lot I'm surprised you don't have a
> > need for N_(), I alway
On 4/6/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 4/6/06, Martin Blais <[EMAIL PROTECTED]> wrote:
>
> > - We could also have a prefix "I" for strings to be marked but not
> > runtime-translated, to replace the N_() strings.
>
> I'm more dub
On 4/6/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> >...
> >A(P(_("Click here to forget"), href="...
> >...
>
> I assume that this should be
>
> P(A(_("Click here to forget"), hre
Hi all
I got an evil idea for Python this morning -- Guido: no, it's not
about linked lists :-) -- , and I'd like to bounce it here. But
first, a bit of context.
In the context of writing i18n apps, programmers have to "mark"
strings that may be internationalized in a way that
- a special hoo
-- Forwarded message --
From: Martin Blais <[EMAIL PROTECTED]>
Date: Mar 29, 2006 10:32 PM
Subject: Python 2.5 update
To: [EMAIL PROTECTED]
Hi
I was thinking of a new action "append_const" to optparse, so I
googled it to check if anybody else had been thinkin
On 12/26/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > A "flat" list or tuple would certainly be more space-efficient up to
> > this point. But when the graph branches, the 2-tuple representation
> > allows *sharing* the common path suffix (which may be very long!):
> ...
> > If there's an N-w
On 12/25/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Tim Peters <[EMAIL PROTECTED]> wrote:
> > Like Phillip Eby, I use 2-tuples for this when I feel the need
> > (usually during a backtracking graph search, to keep track of paths
> > back to the root in a space-efficient way), and am happy wi
On 12/25/05, Christian Tismer <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Python's philosophy about (built-in) data types, inherited from ABC,
> > is to offer a few powerful clearly distinct choices rather than lots
> > of alternatives with overlapping usages. This reduces the time i
On 12/22/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:08 PM 12/22/2005 -0500, Martin Blais wrote:
> >ReST does an amazing job of inferring generic document structures from
> >text, but for documenting source code, you really want to be able to
> >say "
On 12/21/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-12-21 at 20:36 +0100, Fredrik Lundh wrote:
>
> > I'm not really interested in optimizing for you, I'm interested in
> > optimizing
> > for everyone else. They already know HTML. They don't know ReST, and
> > I doubt they care ab
Hello again.
As I'm digging deeper into LISP and Scheme these days, I was
wondering, is there a good compelling reason why in Python we don't
have a native singly-linked and doubly-linked list types?
That is, reasons other than
- "you can get by without it" (sometimes I *want* lists), or
- "you c
On 11/14/05, Bruce Eckel <[EMAIL PROTECTED]> wrote:
> I just finished reading PEP 342, and it appears to follow Hoare's
> Communicating Sequential Processes (CSP) where a process is a
> coroutine, and the communicaion is via yield and send(). It seems that
> if you follow that form (and you don't s
Hi
I find myself occasionally doing this:
... = dirname(dirname(dirname(p)))
I'm always--literally every time-- looking for a more functional form,
something that would be like this:
# apply dirname() 3 times on its results, initializing with p
... = repapply(dirname, 3, p)
There is a
Hi
Just wondering, would anyone think of it as a good idea if the
enumerate() builtin could accept a "start" argument? I've run across
a few cases where this would have been useful. It seems generic
enough too.
___
Python-Dev mailing list
Python-Dev@py
On 10/15/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> > On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> >> Martin Blais <[EMAIL PROTECTED]> writes:
> >>
> >> > How hard would t
On 10/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Martin Blais <[EMAIL PROTECTED]> writes:
>
> > How hard would that be to implement?
>
> import sys
> reload(sys)
> sys.setdefaultencoding('undefined')
Hmmm any p
On 10/3/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > > If that's how things were designed, then Python's entire standard
> > > brary (not to mention third-party libraries) is not "unicode safe" -
> > > to quote your own words - since many functions may return 8-bit strings
> > > containing n
On 10/3/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> > I'm not sure it's a sensible default.
>
> Me neither, especially since this would make it impossible
> to write polymorphic code - e.g. ', '.join(list) wouldn't
> work anymore if list contains Unicode; dito for u', '.join(list)
> with lis
Hi.
Like a lot of people (or so I hear in the blogosphere...), I've been
experiencing some friction in my code with unicode conversion
problems. Even when being super extra careful with the types of str's
or unicode objects that my variables can contain, there is always some
case or oversight whe
On 10/2/05, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 10/3/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> > On 10/1/05, Antoine <[EMAIL PROTECTED]> wrote:
> > >
> > > > like this with their "deferred objects", no? I figure they
On 10/1/05, Antoine <[EMAIL PROTECTED]> wrote:
>
> > like this with their "deferred objects", no? I figure they would
> > need to do something like this too. I will have to check.)
>
> A Deferred object is just the abstraction of a callback - or, rather, two
> callbacks: one for success and one f
Hi.
I hear a confusion that is annoying me a bit in some of the
discussions on concurrency, and I thought I'd flush my thoughts
here to help me clarify some of that stuff, because some people
on the list appear to discuss generators as a concurrency scheme,
and as far as I know (and please correct
On 9/20/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Matthias Andreas Benkard wrote:
>
> * In a recent project, I had occasion to store pathnames of
>picture files in a relational database. I wanted to store
>the pathnames relative to a user-chosen "Pictures"
>directory, so that it could
On 9/19/05, Andrew McNamara <[EMAIL PROTECTED]> wrote:
>
> I agree. I find I often have an object with an optional friendly name
> (label) and a manditory system name. So this sort of thing becomes common:
>
> '%s blah blah' % (foo.label or foo.name)
>
> The if-else-expression alternative wo
On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote:
> > c. Since time is needed to iron out bugs (and perhaps also to reimplememt
> >some pieces of code "from scratch"), very early in the life of Python 3
> >seems like the least-worst
On 9/12/05, Nathan Bullock <[EMAIL PROTECTED]> wrote:
> Just wondering if a function such as this has ever
> been considered? I find that I quite often want a
> function that will give me a relative path from path A
> to path B. I have created such a function, but it
> would be nice if it was in th
On 9/11/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> (Maybe someone else has already raised this point. I'm a bit behind.)
>
> Martin> Here goes something: for applications targeted to the web, where
> Martin> newlines don't matter, the line breaks in _()'ed strings are
> Mar
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 9/4/05, Stephan Deibel <[EMAIL PROTECTED]> wrote:
> On Sun, 4 Sep 2005, Guido van Rossum wrote:
> > But more important to me are my own experiences exploring the
> > boundaries of print.
> >
> > - I quite often come to a point in the evolution of a program where I
> > need to change all print st
On 9/4/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
>
> Yes. If it didn't have the redirect stuff; I would like it more if it also
> didn't have the trailing comma magic. "print" is a fundamental; it deserves
> to be a statement :)
I don't know exactly what you mean by "fundamental", in opposition
On 9/3/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
>
> 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 ca
On 9/3/05, Paolino <[EMAIL PROTECTED]> wrote:
> Martin Blais wrote:
> > Then how about::
> >
> > output(*(x*x for x in range(10)), iter=1)
> >
> Illegal in python2.4.(Wrongly ?) And makes the star solution half unuseful.
>
> >>> def f(*args,*
On 9/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote:
> >Printing the items in a sequence also becomes straightforward:
> >
> >print " ".join(map(str, range(10))) => output(*range(10))
> >
> >Playing well with generator expressions comes for free, to
On 9/2/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > Interestingly enough, the other languages I use most (C, Java,
> > VB(Script) and Javascript (under Windows Scripting Host)) all use
> > functions for output. Except for C, I uniformly dislike the resulting
> > code - the
On 9/2/05, Charles Cazabon <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > >
> > >print('foo:', foo, 'bar:', bar, 'baz:', baz,
> > > 'frobble', frobble)
> > >
> > > To my (admittedly biased) eyes, the second version more obviously
> > > prints to a single line
On 9/1/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > 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 f
On 7/24/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Sunday 24 July 2005 09:34, [EMAIL PROTECTED] wrote:
> > detailed as the full documentation? I'm inclined to think that while it
> > might be a noble goal, it's probably not worth the effort for several
> > reasons.
>
> All your rea
On 7/20/05, Facundo Batista <[EMAIL PROTECTED]> wrote:
> On 7/20/05, Martin Blais <[EMAIL PROTECTED]> wrote:
>
> > it got me wondering, wouldn't it be nice if
> >
> >while:
> > ...
> >
> > behaved as:
> >
> >
Hi
Today I typed something funny in the interactive interpreter:
>>> while:
File "", line 1
while:
^
SyntaxError: invalid syntax
it got me wondering, wouldn't it be nice if
while:
...
behaved as:
while True:
...
Since they appeared, I started using "while T
59 matches
Mail list logo