Re: [Python-Dev] Terminology for PEP 343

[Michael Hudson]

"Raymond Hettinger" <[EMAIL PROTECTED]> writes:

> Another trouble with "resource managed" is that it makes little sense
> even when describing something that is clearly a resource (for instance,
> "locking objects are resource managed", what the heck could that mean,
> there is no hint about the presence of __enter__ and __exit__ or the
> ability to work with the "with" keyword).

At this point, I'm almost liking 'witherator'.  At least it's
something you can look up in the index.

(I think Raymond has identified the problem I have with resource
manager more clearly then I did; I certainly don't think I'd realise
what "decimal.Context() is a resource manager" meant at first
reading).

Cheers,
mwh

-- 
   ucking keyoar
-- from Twisted.Quotes
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Guido van Rossum]

> Guido van Rossum:
> > Then maybe the code that handles Unicode paths in arguments should be
> > fixed rather than adding a module that encapsulates a work-around...

On 7/3/05, Neil Hodgson <[EMAIL PROTECTED]> wrote:
>It isn't clear whether you are saying this should be fixed by the
> user or in the library.

I meant the library.

> For a quick example, say someone wrote some
> code for counting lines in a directory:
[deleted]

Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(".") really behave differently
than os.listdir(u".")? Bah! I don't think that's a very good design
(although I see where it comes from). Promoting only those entries
that need it seems the right solution -- user code that can't deal
with the Unicode entries shouldn't be used around directories
containing unicode -- if it needs to work around unicode it should be
fixed to support that! Mapping Unicode names to "?" seems the
wrong behavior (and doesn't work very well once you try to do anything
with those names except for printing).

Face it. Unicode stinks (from the programmer's POV). But we'll have to
live with it. In Python 3.0 I want str and unicode to be the same data
type (like String in Java) and I want a separate data type to hold a
byte array.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Terminology for PEP 343

[Ron Adam]

Raymond Hettinger wrote:

> There is no value in expanding a concept to the point of being
> meaningless (i.e. meaning whatever you want it to or nothing at all).
> Instead, we need a phrase that expresses the essence of the following:
> 
> 
> abc = EXPR
> exc = (None, None, None)
> VAR = abc.__enter__()
> try:
> try:
> BLOCK
> except:
> exc = sys.exc_info()
> raise
> finally:
> abc.__exit__(*exc)
> 
> There is nothing in that that says resource managed.  The pre/post steps
> could do almost anything from logging, to changing environments, to
> translating, launching/joining unrelated threads, to communicating with
> other processes, etc.  

The name 'abc' is the manager object, so find a better term to replace 
'abc'.

Cheers,
Ron


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Terminology for PEP 343

[Nick Coghlan]

Take II on some draft docs (accuracy of specific examples obviously 
depends on other PEP 343 and PEP 342 related updates).

Based on the various discussions, the following suggests the term 
"suite managers". That focuses on the fact that we're doing something 
before and after the contained suite.

The fact that they bracket a single suite seems to be the only thing 
the assorted uses really have in common, and emphasising that seems to 
work well. It's certainly the first case where I've been able to 
easily explain what decimal.Context does (or will do) when used in a 
'with' statement.

Cheers,
Nick.

"""
With Statements and Suite Management

A frequent need in programming is to ensure a particular action is
taken after a specific section of code has been executed (e.g. closing 
a file, or releasing a lock). The tool to achieve this in Python is 
the 'with' statement. 'with' statements are used to ensure a 
particular action is taken before the contained suite is entered, and 
a second action when the suite is exited.

The precise behaviour of the 'with' statement is governed by the 
supplied suite manager - an object which supports the suite management
protocol. This protocol consists of two methods:

__enter__(self):
  This method is called without arguments before the contained 
suite is entered. If the 'as' clause of the 'with' statement is used, 
the value returned from this method is assigned to the identified target.
  Many suite managers will return self from the __enter__ method, 
but returning a different object may make sense for some managers 
(e.g. see the 'closing' suite manager example below).

__exit__(self, exc_type, exc_value, exc_traceback):
  This method is called after the contained suite has exited. If 
the suite was left due to an exception, the details of that exception 
are passed as arguments. Otherwise, all three arguments are set to None.
  If exception details are passed in, and this method returns 
without incident, then the original exception continues to propagate. 
Otherwise, the exception raised by this method will replace the 
original exception.

Using Suite Managers to Manage Resources

The simplest use of suite management is to strictly control the 
handling of key resources (e.g. files, generators, database 
connections, synchronisation locks).

These resource managers will generally acquire the resource in their 
__enter__ method, although some resource managers may accept the 
resource to be managed as an argument to the constructor or acquire it 
during construction. Resource managers will then release the resource 
in their __exit__ method.

Some resources (e.g. threading.Lock) support the suite management 
protocol natively, allowing them to be used directly in 'with' statements.

While resource management is the most obvious use of the suite 
management protocol, more complex uses are also possible. For example, 
when used as suite managers, decimal.Context objects set themselves as 
the current context before the suite is entered, and then 
automatically revert back to the previous context as the suite is 
exited. This allows the code in the contained suite to manipulate the 
context freely, without needing to worry about manually undoing any 
changes. Other possibilities for suite management include automatic 
exception logging or database transaction handling.

Using Generators to Define Suite Managers

In conjunction with the 'suite_manager' decorator, Python's
generators provide a convenient way to implement the suite
management protocol, and share state between the __enter__ and
__exit__ methods.

The generator must yield exactly once during normal execution. The 
suite manager's __enter__ method executes the generator up to that 
point, and the value yielded is returned. The remainder of the 
generator is executed by the suite manager's __exit__ method. Any 
exceptions that occur in the managed suite will be injected into the 
generator at the location of the yield statement.

For example, the following suite manager allows prompt closure of
any resource with a 'close' method (e.g. a generator or file):

@suite_manager
def closing(resource):
try:
yield resource
finally:
resource.close()
"""
-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] floatobject.c 2.136

[Guido van Rossum]

[Raymond Hettinger]
> > I'm getting a compiler warning from your checkin:

[Michael Hudson]
> "your"?  Mine?

Alas, a typical exchange. The checkins are mailed from the committer's
Sf email address, but the mailing list has been set up to redirect all
replies to python-dev -- if you don't catch this before sending, you
may be embarrassed in public or confuse the addressee.

Is this behavior of the checkins list really a good idea?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Terminology for PEP 343

[Phillip J. Eby]

At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:
>Remember,
>these methods are going to show up in objects such as Context which are
>not primarily about 343.  All of the other methods names will have
>nothing to do with 343, so our choice of magic names needs to be really
>good (as there will likely be NO contextual hints).

with context_expression as variable:
 # perform actions within a context

The "with" statement establishes a context in which some operations are to 
be performed.  Often, this is a resource management context, wherein some 
resource is allocated when the context is entered, and when it is 
exited.  Or it may be a locking context, where a lock is acquired and 
released around the statements.  Or it may be a computational context, such 
as a Decimal context that controls the precision of decimal 
calculations.  In fact, it may be any context that can be defined in terms 
of behavior to be performed when the context is entered and exited.

The object produced by 'context_expression' must have __enter_context__ and 
__exit_context__ methods, which will be invoked by the "with" statement 
when the context is entered, and when it is exited for any reason (such as 
by an exception, "return" statement, or other control flow statements).

...etc.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] floatobject.c 2.136

[Raymond Hettinger]

> Alas, a typical exchange. The checkins are mailed from the committer's
> Sf email address, but the mailing list has been set up to redirect all
> replies to python-dev -- if you don't catch this before sending, you
> may be embarrassed in public or confuse the addressee.
> 
> Is this behavior of the checkins list really a good idea?

I think it should be changed.

In addition to making it a PITA to send notes to the committer, there is
another issue.  For anyone subscribing to python-dev but not the
checkins list, they see conversations started without seeing the history
of checkins that gave rise to those conversations.  Worse, the
resolution of those conversations is often another checkin (which
doesn't get cc'd to python-dev so it is not obvious when there is a
resolution).  For instance, this thread was resolved by Michael's
checkin, 2.137, but you wouldn't know that from reading python-dev.

A few years ago, the cc to python-dev was not automatic and the default
reply address was the original committer.  That worked much better.


Raymond



P.S.  I still don't follow the whole yours/mine comment from Michael.
The offending code line was part of 2.136 which CVS says was checked-in
by him on 5/27/2005 and then fixed by him on 6/30/2005.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] floatobject.c 2.136

[Michael Hudson]

On 4 Jul 2005, at 18:59, Raymond Hettinger wrote:

> P.S.  I still don't follow the whole yours/mine comment from Michael.
> The offending code line was part of 2.136 which CVS says was checked-in
> by him on 5/27/2005 and then fixed by him on 6/30/2005.

Well, my confusion started and ended with the fact that a mail to 
python-dev with no obvious indication of being a reply to anything used 
the word "your", without a name or any indication of who you were 
addressing.  I'm afraid I don't remember the exact revisions of the 
exact files I've checked in recently :)

Cheers,
mwh

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Terminology for PEP 343

[Raymond Hettinger]

[Phillip J. Eby]
>
> with context_expression as variable:
>  # perform actions within a context
> 
> The "with" statement establishes a context in which some operations
are to
> be performed.  Often, this is a resource management context, wherein
some
> resource is allocated when the context is entered, and when it is
> exited.  Or it may be a locking context, where a lock is acquired and
> released around the statements.  Or it may be a computational context,
> such
> as a Decimal context that controls the precision of decimal
> calculations.  In fact, it may be any context that can be defined in
terms
> of behavior to be performed when the context is entered and exited.
> 
> The object produced by 'context_expression' must have
__enter_context__
> and
> __exit_context__ methods, which will be invoked by the "with"
statement
> when the context is entered, and when it is exited for any reason
(such as
> by an exception, "return" statement, or other control flow
statements).

This is much improved.  I think we're getting close.
So far, I like Nick's most recent version the best,
but this is in the ballpark.

The new methods names are a step in the right direction
but they are butt-ugly and unfriendly.  It is much cleaner looking
and equally communicative to write __beginwith__ and __endwith__.
Those names are clearly bookends and associated with with-suites.
They are shorter, more pithy, and don't abuse underscore conventions
(the current worst offenders are test___all__.py and the set module's
__as_temporarily_immutable__ attribute which gives me COBOL flashbacks).



[Nick Coghlan]
> Based on the various discussions, the following suggests the term
> "suite managers". That focuses on the fact that we're doing something
> before and after the contained suite.
> 
> The fact that they bracket a single suite seems to be the only thing
> the assorted uses really have in common, and emphasising that seems to
> work well. It's certainly the first case where I've been able to
> easily explain what decimal.Context does (or will do) when used in a
> 'with' statement.

I think you're onto something.  Stick with it.  Your whole write-up is
clear.  It is the first one that doesn't look like it had to twist its
metaphor into a knot.
 


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Money module

[Facundo Batista]

On 7/2/05, Aahz <[EMAIL PROTECTED]> wrote:

> Sounds like a better way to go is a Money package (or perhaps a Financial
> package) and just create the Currency module within it for now.  Anyway,

Something to consider!


> given that this isn't going to be a real PEP any time soon, please
> restrict the discussion to comp.lang.python.  Thanks for your help
> keeping python-dev clutter-free.  ;-)

Well, there's a separate list for the discussions, pymoney-general
(accesable through the project in SF). This post was only for tell you
people that if you're interested, this is a good moment to jump in.

Regards,

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Thomas Heller]

Neil Hodgson <[EMAIL PROTECTED]> writes:

> 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 sys.argvu and
> os.environu are provided and os.system accepts unicode arguments
> similar to PEP 277. A screenshot showing why the existing features are
> inadequate and the new features an enhancement are at
> http://www.scintilla.org/pyunicode.png
>One problem is that when using "python -c cmd args", sys.argvu
> includes the "cmd" but sys.argv does not. They both contain the "-c".

Not only that, all the other flags like -O and -E are also in sys.argvu
but not in sys.argv.

>os.system was changed to make it easier to add some test cases but
> then that looked like too much trouble. There are far too many
> variants on exec*, spawn* and popen* to write a quick patch for these.

Those are nearly obsoleted by the subprocess module (although I do not
know how that handles unicode.

Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-dev Summary for 2005-06-16 through 2005-06-30 [draft]

[Steven Bethard]

Here's our draft of the summary for the second half of June.  As
usual, please let me, Tony or Tim know if you have any comments or
corrections.

-- Steven Bethard

=
Summary Announcements
=

--
OSCON Registration
--

Though if you haven't yet registered, you've already missed the early
registration period (which ended June 20), you should still consider
taking a look at the O'Reilly Open Source Convention (OSCON). Guido
assures us that "the Python program is really good!"

Contributing Thread:

- `Please spread the word about OSCON early reg deadline
`__

=
Summaries
=


PEP Clean Up


Raymond Hettinger decided to go through the `list of PEPs`_ and do
some spring cleaning (late for the Northern Hemisphere, but early down
south).

* Rejection of `PEP 303`_ ("Extend divmod() for Multiple Divisors")
was proposed on the grounds that it has been open for two and half
years and hasn't generated discussion or support, is unpersuasive, and
unnecessary.  No-one spoke up for it (and some against), so it is now
rejected.

* Rejection of `PEP 254`_ ("Making Classes Look More Like Types") was
proposed on the grounds that it is only an empty stub and is unlikely
to ever get filled-out.  No-one spoke up either way, and it is now
rejected.

* Rejection of `PEP 265`_ ("Sorting Dictionaries by Value") was
proposed on the grounds that as of Python 2.4 its use case is easily
solved with a one-line sorted() solution.  Several people agreed, and
no-one disagreed, so the PEP is now rejcted.

* Rejection of `PEP 276`_ ("Simple iterator for ints") was proposed on
the grounds that the principal use case was largely met by enumerate()
and that the proposed syntax was problematic.  Guido agreed, so the
PEP was rejected.
   
* Rejection of `PEP 281`_ ("Loop Counter Iteration with range and
xrange") was proposed on the grounds that it too was solved by the
enumerate() built-in.  Guido agreed again, and this PEP too was
rejected.

* Rejection of `PEP 294`_ ("Type Names in the types Module") was
proposed on the grounds that a centralized repository of type names
was a mistake and that neither the "types" nor "new" modules should be
carried forward to Python 3.0.  No-one disagreed, and the PEP was
rejected.

* Rejection of `PEP 313`_ ("Adding Roman Numeral Literals to Python" -
yes, this is a real PEP!) was proposed, and the PEP was rejected.

* Rejection of `PEP 336`_ ("Make None Callable") was proposed on the
grounds that no support has grown beyond the original poster, and that
it fails the tests of obviousness, necessity, clarity, and
explicitness.  Many people, including Guido, agreed, and the PEP was
rejected.

* Raymond suggested updating `PEP 284`_ ("Integer for-loops"), but
several people spoke up against it, including Guido, so the PEP was
rejected.

* Raymond asked whether `PEP 330`_ ("Python Bytecode Verification")
had any known uses.  Guido said that he believes that a verification
tool has some value, but if someone wants to add it to Tools/scripts,
no PEP is required, so the PEP was rejected.

* A.M. Kuchling volunteered to take over `PEP 206`_ ("Python Advanced
Library", or the "Batteries Included" PEP) and rewrite it to describe
a set of third-party packages to complement the standard library. 
This was approved, and so he's now the maintainer.

* Raymond suggested accepting `PEP 312`_ ("Simple Implicit Lambda"),
which resulted in the most discussion of any of the PEP
recommendations.  However, Guido hates the unary colon syntax, and it
was decided that the PEP needs to go back to the drawing board and
find a more Pythonic syntax (perhaps an alternative unary operator). 
The PEP is now deferred.

* Raymond asked whether `PEP 237`_ ("Unifying Long Integers and
Integers") was now complete and could be marked as final.  Guido noted
that it was complete for 2.x, but that phase C will be implemented in
Python 3.0, as the PEP states.  He indicated that he would be fine
with marking `PEP 237`_ as final and moving this phase to `PEP 3000`_;
at the time of writing, this hadn't been done yet.

.. _list of PEPs: http://.python.org/peps
.. _PEP 303: http://www.python.org/peps/pep-0303.html
.. _PEP 265: http://www.python.org/peps/pep-0265.html
.. _PEP 254: http://www.python.org/peps/pep-0254.html
.. _PEP 276: http://www.python.org/peps/pep-0276.html
.. _PEP 281: http://www.python.org/peps/pep-0281.html
.. _PEP 294: http://www.python.org/peps/pep-0294.html
.. _PEP 313: http://www.python.org/peps/pep-0313.html
.. _PEP 336: http://www.python.org/peps/pep-0336.html
.. _PEP 284: http://www.python.org/peps/pep-0284.html
.. _PEP 330: http://www.python.org/peps/pep-0330.html
.. _PEP 206: http://www.python.org/peps/pep-0206.html
.. _PEP 312: http://www.python.org/peps/pep-0312.html
.. _PEP 237: http://www.python.org/peps/pep-0237.html
.. _PEP 3000: http://www

Re: [Python-Dev] Terminology for PEP 343

[Delaney, Timothy (Tim)]

Phillip J. Eby wrote:

> Expand your mind.  :) "Resource" can include whatever objects you
> want it 
> to -- or no objects at all.  A resource can be conceptual - like for
> example the user's attention, or the contents of a status bar or log
> message, or the timing/profiling of an activity.  I think maybe you're

Well, HR considers me to be a resource ... ;)

Personally, I'm very happy with considering anything a with statement
manages as a resource.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python-dev Summary for 2005-06-16 through 2005-06-30 [draft]

[Aahz]

Nothing to say, just keep up the good work!  I hope the triple-team
approach is still working well.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Neil Hodgson]

Thomas Heller:

> Not only that, all the other flags like -O and -E are also in sys.argvu
> but not in sys.argv.

   OK, new patch fixes these and the "-c" issue.

> Those are nearly obsoleted by the subprocess module (although I do not
> know how that handles unicode.

   It breaks. The argspec is zzOOiiOzO:CreateProcess.

>>> z = subprocess.Popen(u"cmd /c echo \u0417")
Traceback (most recent call last):
  File "", line 1, in ?
  File "c:\zed\python\dist\src\lib\subprocess.py", line 600, in __init__
errread, errwrite)
  File "c:\zed\python\dist\src\lib\subprocess.py", line 791, in _execute_child
startupinfo)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0417' in
position 12: ordinal not in range(128)

   Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com