[Greg Ewing]
>> All development is done in house by French people. All documentation,
>> external or internal, comments, identifier and function names,
>> everything is in French.
> There's nothing stopping you from creating your own Frenchified
> version of Python that lets you use all the c
Martin Blais wrote:
> 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)
Maybe ** should be defined for functions so that you
could do
François Pinard wrote:
> All development is done in house by French people. All documentation,
> external or internal, comments, identifier and function names,
> everything is in French.
There's nothing stopping you from creating your own
Frenchified version of Python that lets you use all
the
Guido van Rossum wrote:
>Help!
>
>What's the magic to get $Revision$ and $Date$ to be expanded upon
>checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the
>latter has the svn revision and date in the headers, while the former
>still has Brett's original revision 1.5 and a date somew
[Guido van Rossum]
>What's the magic to get $Revision$ and $Date$ to be expanded upon
>checkin?
Expansion does not occur on checkin, but on checkout, and even then,
only in your copy -- that one you see (the internal Subversion copy is
untouched). You have to edit a property for the file where
[Guido]
> Help!
>
> What's the magic to get $Revision$ and $Date$ to be expanded upon
> checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the
> latter has the svn revision and date in the headers, while the former
> still has Brett's original revision 1.5 and a date somewhere in June
Help!
What's the magic to get $Revision$ and $Date$ to be expanded upon
checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the
latter has the svn revision and date in the headers, while the former
still has Brett's original revision 1.5 and a date somewhere in June.
I tried to fix th
I thought about something -
>
> I think that the performance penalty may be rather small - remember
> that in programs which do not change strings, there would never be a
> need to copy the string data at all. And since I think that usually
> most of the dict lookups are for method or function name
On 10/31/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> 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)
[...]
> Just wondering, does an
On 10/31/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
> And I'm going to point out why you are wrong.
I still don't think so. I think that I need to reclarify what I mean.
> > About the users-changing-my-internal-data issue:
...
> You can have a printout before it dies:
> "I'm crashing your
Noam Raphael <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have slept quite well, and talked about it with a few people, and I
> still think I'm right.
And I'm going to point out why you are wrong.
> About the users-changing-my-internal-data issue:
>
> > Again, user semantics. Tell your users not
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> [...]
> >>Perhaps I didn't make it clear. The difference between wxPython's Grid
> >>and my table is that in the table, most values are *computed*. This
> >>means that there's no point in changing the values themselves. They
> >>
On Mon, Oct 31, 2005, Martin Blais wrote:
>
> There is a way to hack something like that with reduce, but it's not
> pretty--it involves creating a temporary list and a lambda function:
>
> ... = reduce(lambda x, y: dirname(x), [p] + [None] * 3)
>
> Just wondering, does anybody know how to do t
Hello,
I have slept quite well, and talked about it with a few people, and I
still think I'm right.
About the users-changing-my-internal-data issue:
> Again, user semantics. Tell your users not to modify entries, and/or
> you can make copies of objects you return. If your users are too daft
>
I've made a final pass over PEP 352, mostly fixing the __str__,
__unicode__ and __repr__ methods to behave more reasonably. I'm all
for accepting it now. Does anybody see any last-minute show-stopping
problems with it?
As always, http://python.org/peps/pep-0352.html
--
--Guido van Rossum (home pa
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
Martin v. Löwis wrote:
> Steve Holden wrote:
>
>>Therefore, if such steps are really going to be considered, I would
>>really like to see them introduced in such a way that no breakage occurs
>>for existing users, even the parochial ones who feel they (and their
>>programs) don't need to unders
Steve Holden wrote:
> Therefore, if such steps are really going to be considered, I would
> really like to see them introduced in such a way that no breakage occurs
> for existing users, even the parochial ones who feel they (and their
> programs) don't need to understand anything but ASCII.
It
On 10/31/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > It allows everything in Python to be both mutable and hashable,
>
> I don't understand, since it's already the case. Any user-defined object
> is at the same time mutable and hashable.
By default, user-defined objects are equal iff they
Josiah Carlson wrote:
[...]
>>Perhaps I didn't make it clear. The difference between wxPython's Grid
>>and my table is that in the table, most values are *computed*. This
>>means that there's no point in changing the values themselves. They
>>are also used frequently as set members (I can describe
Adam Olsen wrote:
> On 10/30/05, François Pinard <[EMAIL PROTECTED]> wrote:
>
>>All development is done in house by French people. All documentation,
>>external or internal, comments, identifier and function names,
>>everything is in French. Some of the developers here have had a long
>>programm
I wonder if, once PEP 352 is accepted, this shouldn't be changed so
that there is only one except clause instead of two, and it says
"except Exception:". This has roughly the same effect as the proposed
(and already applied) patch, but does it in a Python-3000-compatible
way. ATM it is less robust
Gustavo Niemeyer niemeyer.net> writes:
>
> The StreamHandler available under the logging package is currently
> catching all exceptions under the emit() method call. In the
> Handler.handleError() documentation it's mentioned that it's
> implemented like that because users do not care about erro
23 matches
Mail list logo
