Raymond Hettinger wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
Witty objects?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Raymond Hettinger wrote:
> Whatever term is selected, it should be well thought-out and added to
> the glossary. The choice of words will likely have a great effect on
> learnability and on how people think about the new tool.
When writing PEP 346, I ended up choosing "user defined statement" as
I'm preparing the pre-PEP of a Money module, and I don't want to
explain the rounding methods there again.
So my idea was to point to Decimal documentation regarding them. And I
couldn't find them.
Could it be we missed the explanation of each rounding mode in the
Decimal docs? Or the sprints bur
Facundo Batista wrote:
> I'm preparing the pre-PEP of a Money module, and I don't want to
> explain the rounding methods there again.
>
> So my idea was to point to Decimal documentation regarding them. And I
> couldn't find them.
>
> Could it be we missed the explanation of each rounding mode in
On Fri, Jul 01, 2005, Darryl Dixon wrote:
>
> Is it worth sending in a patch to the sourceforge patch-tracker
> implementing this? Is it OK for msvcrt_getch to return Unicode when
> appropriate?
Let's put it this way: you probably won't get much in the way of forward
motion on this unless you do
On Fri, Jul 01, 2005, Facundo Batista wrote:
>
> I'm preparing the pre-PEP of a Money module, and I don't want to
> explain the rounding methods there again.
>
> So my idea was to point to Decimal documentation regarding them. And I
> couldn't find them.
>
> Could it be we missed the explanation
On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote:
> My suspicion is that someone at some point thought that Cowlishaw was
> sufficient; we probably should write some base-level docs that explain
> the Python mechanisms and refer to Cowlishaw for details.
Well, it's already well explained, with examples
"Darryl Dixon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Python on Windows. The Python interface to this function is in the C
> code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
> OS system call.
I think Fredrik made two points in this regard. 1) The cu
On Thu, 2005-06-30 at 22:41, Raymond Hettinger wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
Their raison d'etre is to bracket user code with setup and teardown
methods, so how about
> http://www.python.org/peps/pep-0327.html#rounding-algorithms
>
> I'll point to there from the Money PEP, but I think this should be
> somewhere in the docs. I mean, as a final user, you shouldn't read a
> PEP or a 3rd party doc to know how to use a module.
I've got it from here. Will update th
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
>With 343 accepted, we can now add __enter__() and __exit__() methods to
>objects.
>
>What term should describe those objects in the documentation?
Resource managers.
___
Python-Dev mailing list
Pyth
On Friday 01 July 2005 08:55, Facundo Batista wrote:
> I'll point to there from the Money PEP, but I think this should be
> somewhere in the docs. I mean, as a final user, you shouldn't read a
> PEP or a 3rd party doc to know how to use a module.
Please file a documentation bug on SF, with this
On Fri, Jul 01, 2005, Facundo Batista wrote:
> On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote:
>>
>> My suspicion is that someone at some point thought that Cowlishaw was
>> sufficient; we probably should write some base-level docs that explain
>> the Python mechanisms and refer to Cowlishaw for detail
On Friday 01 July 2005 11:36, Raymond Hettinger wrote:
> I've got it from here. Will update the docs.
Dang, a race condition. :-)
Ok, Facundo, never mind the SF tracker item.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev
On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
> Resource managers.
Yeah, I was thinking that, but was somewhat ambivalent. But I definately like
it better than anything else proposed so far.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev ma
On 7/1/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 01 July 2005 11:36, Raymond Hettinger wrote:
> > I've got it from here. Will update the docs.
>
> Dang, a race condition. :-)
>
> Ok, Facundo, never mind the SF tracker item.
:p.
My original idea was to ask you for another
On 7/1/05, Aahz <[EMAIL PROTECTED]> wrote:
> Agreed. Unfortunately, that's one big area where Python needs work;
> new-style classes are probably the worst. If you wanted to take the
> lead and push a sprint on doc work, you'd be a hero.
Ehhh... what a good idea for PyCon 2006!!
:D
.Facun
On 7/1/05, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
> > Resource managers.
>
> Yeah, I was thinking that, but was somewhat ambivalent. But I definately like
> it better than anything else proposed so far.
>
I say we steal from the C++
People:
The Money two-days sprint in EuroPython 2005 has finished.
We advanced a lot. The pre-PEP is almost done, and the corresponding
test cases are all written.
We need to finish the structure procesing for currency general
information, and bring general functions to the module, but most of
t
On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote:
> > If there are no objections, I propose to do the following (only in
> > Python 2.4 and 2.5):
> >
> > * Add set.union_update() as an alias for set.update().
>
> No. It was intentional to drop the duplicate method with the
> hard-to-u
[Brett Cannon]
> I say we steal from the C++ and the RAII paradigm and go with RMUW
> (Resource Management Using 'with'
Or the-keyword-formerly-known-as-do
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
[Facundo]
> The pre-PEP is almost done, and the corresponding
> test cases are all written.
What is the part about the pre-PEP? Something like this probably
shouldn't go in the standard library until it has been proven in the
field. This doubly true for a module that has made some unusual OO
des
Nick Coghlan wrote:
> Raymond Hettinger wrote:
>
>>Whatever term is selected, it should be well thought-out and added to
>>the glossary. The choice of words will likely have a great effect on
>>learnability and on how people think about the new tool.
I tried to bring this up on python-list, but
Raymond Hettinger wrote:
> Several thoughts:
As I told you in a private dicussion, you have convinced me about copy.
About clear, however, I feel I have to defend my colleagues and
myself, who almost all wasted time once (but only once) searching how to
clear a list. Improving the docs (like
[Raymond]
> >>Whatever term is selected, it should be well thought-out and added
to
> >>the glossary. The choice of words will likely have a great effect
on
> >>learnability and on how people think about the new tool.
[Ron Adam]
> I tried to bring this up on python-list, but I didn't get much of
Raymond writes:
> On a separate note, I also propose that __exit__() be renamed to
> __leave__(). The enter/leave word pairing are a better fit in standard
> English:
I don't feel strongly about it, but I tend to disagree. Certainly you
will admit that enter-exit IS a gramatically correct pairing
> I would use "She left the ballpark." for someone walking into the
> dugout, climbing up into the stands, or walking out of the stadium,
> and might refer to the entire process. Using "She exited the
ballpark."
> to me suggests the exact moment that she went through the door
> dividing outside fro
Hi,
I often find myself writing:
class grouping:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
I hate it, and every time I show this to a Python newcomer I get that
skeptic look. How about this for a change?
class grouping:
def __i
At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
>Hi,
>
>I often find myself writing:
>
> class grouping:
>
> def __init__(self, x, y, z):
> self.x = x
> self.y = y
> self.z = z
>
>I hate it, and every time I show this to a Python newcomer I get that
On Fri, 01 Jul 2005 19:22:20 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote:
> [snip]
>
>This extends to any number of arguments:
>
> class grouping:
> def __init__(self, x, y, z):
> self.__dict__.update(locals(
I am happy to see that others agree we need something better
than self.x=x; self.y=y; self.z=z.
Phillip J. Eby wrote:
>class grouping:
>def __init__(self, x, y, z):
>initialize(self, locals())
Been there (older code):
http://phenix-online.org/cctbx_sources/scitbx/scitbx
Jp Calderone wrote:
> If you use vars(self).update(locals()), it even looks halfway
> pleasant ;) I'm not sure what python-dev's current opinion of
> vars(obj) is though (I'm hoping someone'll tell me).
>
> Of course, both of these fall over for __slots__'ful classes. It'd
> be nice if there wer
Michael Chermside wrote:
> In favor of "exit" over "leave" I have only two arguments. First, I
> just like "exit" better. Hmm... didn't find that compelling? I was
> afraid of that.
I have a pretty simple reason for liking the enter/exit pair over the
enter/leave pair.
In the former case, both w
Jp Calderone wrote:
> If you use vars(self).update(locals()), it even looks halfway
> pleasant ;) I'm not sure what python-dev's current opinion of
> vars(obj) is though (I'm hoping someone'll tell me).
http://docs.python.org/lib/built-in-funcs.html#l2h-76 is pretty clear:
vars([object])
W
Raymond Hettinger wrote:
> On a separate note, I also propose that __exit__() be renamed to
> __leave__(). The enter/leave word pairing are a better fit in standard
> English:
I tend to associate leave with leaving, and leaving with arriving.
I didn't even think the __enter__ / __exit__ names w
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jp Calderone wrote:
> > If you use vars(self).update(locals()), it even looks halfway
> > pleasant ;) I'm not sure what python-dev's current opinion of
> > vars(obj) is though (I'm hoping someone'll tell me).
> >
> > Of course, both of these fall over fo
Thomas Heller:
> OTOH, Python is lacking a lot when you have to handle unicode strings on
> sys.path, in command line arguments, environment variables and maybe
> other places.
A new patch #1231336 "Add unicode for sys.argv, os.environ,
os.system" is now in SourceForge. New parallel features
Josiah Carlson wrote:
> Now, don't get me wrong, definining __slots__ can be a pain in the
> tookus, but with a proper metaclass, that metaclass can define the
> __slots__ attribute based on the argument list for __init__().
>
> There you go.
Where? The meta-class idea sounds interesting. Could y
Ralf W. Grosse-Kunstleve wrote:
> I know enhancing the syntax is work, but shouldn't a syntax leading to
> less code clutter be the higher value? IMO a long-term gain counts for
> much more than avoiding a one-time investment implementing a useful
> feature. Take, for example, the syntax enhancemen
On Fri, Jul 01, 2005, Ralf W. Grosse-Kunstleve wrote:
>
> I often find myself writing:
>
> class grouping:
>
> def __init__(self, x, y, z):
> self.x = x
> self.y = y
> self.z = z
>
> I hate it, and every time I show this to a Python newcomer I get that
> sk
On Saturday 02 July 2005 08:59, Ralf W. Grosse-Kunstleve wrote:
> I hate it, and every time I show this to a Python newcomer I get that
> skeptic look. How about this for a change?
>
> class grouping:
>
> def __init__(self, .x, .y, .z):
> pass
-1. Syntax should not look like grit
41 matches
Mail list logo
