Re: [Python-Dev] Chaining try statements: eltry?

[Greg Ewing]

Guido van Rossum wrote:

> I sometimes think it was
> a mistake to introduce elif just to save typing "else if".
> 
> The problem with the elwhile/elfor/eltry idea 
 > is that you're just as likely to need e.g.
> a "try" in the else clause of a while-loop as another while,

Here's an idea for Python 3000 which addresses both of
these: Split 'elif' back up into 'else if', but also
generalise it so that any 'else' can be followed by any
suite-introducing statement. Then you get all possible
combinations for free.

Greg

___
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:

> But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
> this file as module.  Internally Python\import.c converts everything to
> strings.  I started to refactor import.c to work with PyStringObjects
> instead of char buffers as a first step - PyUnicodeObjects could have
> been added later, but I gave up because there seems absolute zero
> interest in it.

   Well, most people when confronted with this will rename the
directory to something simple like "ulib" and continue.

> I can't judge on this - but it's easy to experiment with it, even in
> current Python releases since sys.argvu, os.environu can also be
> provided by extension modules.

   It is the effect of this on the non-unicode-savvy that is
important: if os.environu goes into prereleases of 2.5 then the only
people that will use it are likely to be those who already try to keep
their code unicode compliant. There is only likely to be (negative)
feedback if existing features are made unicode-only or use unicode for
non-ASCII.

> But thanks that you care about this stuff - I'm a little bit worried
> because all the other folks seem to think everything's ok (?).

   Unicode is becoming more of an issue: many Linux distributions now
install by default with a UTF8 locale and other tools are starting to
use this: GCC 4 now delivers error messages using Unicode quote
characters like 'these' rather than `these'. There are 131 threads
found by Google Groups for (UnicodeEncodeError OR UnicodeDecodeError)
and 21 of these were in this June. A large proportion of the threads
are in language-specific groups so are not as visible to core
developers.

   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

Re: [Python-Dev] checklist for filing a bug

[Terry Reedy]

"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>> In order to lower the barrier for reporting bugs, writing patches, and
>> handling CVS commits, I am writing up checklists for each and I will
>> put them up on python.org.
>
> -0 on the checklists.

I am more enthusiastic about the idea of improving python.com's guidelines 
in this area, with some of Raymond's comments, and mine below, taken into 
consideration.  To start with, I think the Developers page should have Bug 
Submission Guidelines to go with the Patch Submission Guidelines.

Searching the site for 'bug reports' gives PEP 3 *Handling* (not 
submitting) Bug Reports as first hit.  It seems to have last been revised 
4-5 years ago.  Is there anything more recent I should be aware of?  PEP 3 
references Appendix B. Reporting Bugs of the current docs.  I believe this 
page could stand revision to be more list a checklist.

The search engine does *not* return this page (current App. B) among the 
first 10 of 19,000 (really?) reported hits.  I wish we could 'buy' words 
(for free) for searches on our own site or otherwise learn how to influence 
the search results.  The top 10 do include the appendix for earlier 
versions.  But this will won't help get people to the most recent version.

The search engine also reports Known Bugs lists such as 
http://www.python.org/2.4/bugs.html.
At the bottom is a very short blurb of how to report bugs, which does 
reference Appendix B (nor, of course, to your yet to be posted page).  The 
same applies to http://www.python.org/dev/tools.html.  I would really like 
to see one page, occasionally revised, that is referenced wherever the 
subject is discussed on the site.

Some specifics based on my experience reviewing bugs, mostly as 'triage 
nurse'.

I would like to see more emphasis that the Python SF bug list is for bugs 
in the PSF distribution, including documentation and std libs, which we can 
fix, and not for other stuff, including feature requests (see RFE tracker), 
non-bug change proposals (see PEPs), and bugs in 3rd party libraries and 
compilers (see their bug lists).

I would like it stated that a bug is generally a discrepancy between 
promise -- the documentaion-- and performance -- the implementation. 
(Non-documentation is another area.)  This means that 'reporting a bug' 
often means finding and reporting the section of the documentation -- the 
language or library reference -- that conflicts with the reported behavior. 
Many bugs reported today are not as obviously bugs as
>>> 2+2
5

I agree with Raymond that unittests are a nice optional extra but too much 
to expect.  You could mention that providing good, simple code 
demonstrating the bug, perhaps with multiple data inputs, makes it easier 
for the bug fixer to write a test so that the bug will be caught if 
reintroduced.

In summary, I think a good guideline page could improve reports and make 
first-reviews easier.

Terry J. Reedy



___
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] Linux Python linking with G++?

[David Abrahams]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> David Abrahams wrote:
>>>If there is some library with such objects that happens to get
>>>wrapped and dynamically linked into a Python interpreter 
>> 
>> 
>> Whoa there.  How would that ever happen under ordinary circumstances?
>> Doesn't Python's makefile control what gets linked to Python?
>
> Not entirely. By extending Modules/Setup 

You mean 
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
?

> e.g. in the way freeze works), it is well possible to have
> additional extension modules linked into the Python interpreter,
> extension modules which are not part of the standard Python
> distribution.
>
> In fact, before Python supported dynamic loading of extension
> modules, this was the *only* way to use non-standard extension
> modules. You always had to build your own version of the Python
> interpreter. I believe ccpython.cc dates back to these times.

That explains a lot.  

I contend that either:

   a.  Anyone making that sort of extension with a C++ module should
   explicitly request --with-cxx, or

   b.  The python build system should automatically detect that
   --with-cxx is needed based on the presence of C++ extension
   modules.

Frankly I think b. would require an impractical amount of work and,
speaking as an author of C++ extension modules, I don't think a. is
much of a burden to impose.

>> If there's someone around here who is responsible for this change and
>> knows its real rationale, can (s)he please tell me what it is?  If
>> not, can we please change things back so Python doesn't get linked to
>> the C++ runtime by default?
>
> ccpython.cc and --with-cxx was first published in Python 1.6, and
> hasn't changed much since. So for some of you, it has "always" been
> there. It was contributed by Geoff Furnish.
>
> What *has* changed now is that the configure test suddenly
> determines that you need to link with g++ on Linux if main was
> compiled with g++.  This was not the case before, but now is (since
> g++ 3.2 or something).

I see.  Well, everything has become clear, thank you.  My proposed
remedy hasn't changed, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.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] GCC version compatibility

[David Abrahams]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> David Abrahams wrote:
>>>When I looked into this problem I saw that configure in fact builds a test
>>>executable that included an object file compiled with g++. If the link step
>>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>>used. Obviously, on my system this test was successful so configure decided
>>>to link with gcc. However, minimal changes to the source of the test program
>>>caused the link step to fail. It was not obvious to me at all why the latter
>>>source code should cause a dependency on the C++ runtime if the original
>>>code does not. My conclusion was that this test is fragile and should be
>>>skipped. 
>> 
>> 
>> Sounds like it.  I have never understood what the test was really
>> checking for since the moment it was first described to me, FWIW.
>
> I'll describe it once more: *If* a program is compiled with the C++
> compiler, is it *then* possible to still link it with the C compiler?
> This is the question this test tries to answer.

Okay, I understand that.  What I have never understood is why that
should be an appropriate thing to test for the Python executable.
There's no reason to compile any of Python with a C++ compiler.

>>>If Python is built with --with-cxx then it should be linked with CXX
>>>as well.
>> 
>> U betcha.
>
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. 

Apparently it still does.

> On these Linux systems, it was well possible to build main() with a
> C++ compiler

Nobody would need to build Python's main() with a C++ compiler, if
you'd just comment out the 'extern "C"'.

> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.

It isn't.

>>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>>
>>> * when is --with-cxx really necessary?
>> 
>> 
>> I think it's plausible that if you set sys.dlopenflags
>
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).

I have tested Boost.Python and C++ extension modules on a wide variety
of Linux systems, and have seen this phenomenon.  Everyone who is
testing it on Linux is finding that if they build Python
--without-cxx, everything works.  And, yes, the mechanisms at the very
*core* of Boost.Python rely on static initializers being run properly,
so if there were anything wrong with that mechanism the tests would be
breaking left and right.

I think either the ELF Linux loader changed substantially since 1995,
or whoever introduced this test was just confused.

C++ extension modules get their static initializers run when they are
loaded by dlopen (or, strictly speaking, sometime between then and the
time their code begins to execute) which happens long after main or
__main are invoked.  The executable doesn't know about these extension
modules until they are loaded, and when it loads them it can't get its
hooks into anything other than the initmodulename entry point.  The
executable does not trigger the static initializers; the dynamic
loader does.  Therefore, it doesn't matter whether the executable is
linked with the C++ runtime.  An appropriate C++ runtime is linked to
the extension module and that is what gets invoked when the module is
loaded.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.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] Linux Python linking with G++?

[David Abrahams]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> David Abrahams wrote:
>> Unless, of course, I'm missing something.  So if I am missing
>> something, what is it?
>
> You are missing something, and I can only repeat myself. Some systems
> require main() to be compiled as C++, or else constructors may not work
> (and perhaps other things fail as well). 

Yes, and that becomes important in programs that have constructors.
I.e., C++ programs.  The Python executable is not such a program,
except for one C++ file: ccpython.cc.  There is no reason that file
couldn't be rewritten as a pure 'C' file and any need for Python to be
linked with G++ would disappear.

> The configure option --with-cxx (documented as "enable C++ support")
> make Python C++ options 

What are "Python C++ options?"

> work on such systems. It is automatically enabled if a C++ compiler
> is found.
>
> There is configure auto-detection for what linker is used when
> ccpython.o becomes main().
>
> This is the state of the things as it is. In what way would you like to
> see that state changed?

I would like the Python executable never to be linked (or compiled
either) by g++ unless that is explicitly requested by the person
invoking configure or make.

> I could personally accept if ccpython and --with-cxx would be dropped
> entirely (i.e. deliberately breaking systems which require it); 

I don't believe any systems require it.  I realize you have said
otherwise, but after years of working with Boost.Python I'm very
familiar with the issues of dynamic linking and C/C++ interoperability
on a wide variety of platforms, and I'm not convinced by your
assertion.  If such a system exists, it should be easy for someone to
point me at it, and show that something breaks.

> I just notice the irony of history: ccpython.cc was originally
> introduced to better support C++ extension modules - now it might
> get removed for the very same reason (to better support C++
> extension modules).

Indeed.  I was amazed to read in the log that it was introduced in
1995 for that reason.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.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] Possible context managers in stdlib

[Nick Coghlan]

Michael Chermside wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
> 
> This achieves two things: it makes them available to those who need
> them (not everyone uses threads!), and it rather forcefully makes the
> point that it's NOT usually a good idea to modify global state info in
> a context manager because doing so is not generally threadsafe.

Wouldn't they be able to actually emit a warning at run-time if they're used 
in a multi-threaded program? That would be even better motivation for 
including them, IMO.

Cheers,
Nick.

-- 
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Nick Coghlan]

Terry Reedy wrote:
> Would this also work as a decorated generator?
> (If I have understood correctly, something like..)
> 
> @contextmanager
> def tag(name)
>print "<%s>" % name
>yield None
>print "" % name
> 
> If so, I suggest putting in both versions to make the correspondence clear.

Hmm, good idea. I think I'll do that with 'closing' as well, since the 
resource management section could use a better example.

> To whoever invented this example: thanks.  It rang a bell with me so I 
> could see this as a generally usefully feature rather than a specialized 
> (though for some, important) 'close resource' feature.
> 
> The particularly neat thing is that it converts the indent-dedent method of 
> showing structure to the alternative matched-fences method.   This is 
> certainly not limited to HTML generation.

By using closing(), decimal.getcontext(), and tag() as examples, it should be 
possible to show the versatility of the construct without making the 
documentation too confusing.

Cheers,
Nick.

[1] http://www.python.org/sf/1234057

-- 
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Nick Coghlan]

M.-A. Lemburg wrote:
> May I suggest that you use a different name than "context" for
> this ?!
> 
> The term "context" is way to broad for the application scopes
> that you have in mind here (like e.g. managing a resource
> in a multi-threaded application).

It's actually the broadness of the term 'context' which is appealing - the 
examples in the draft documentation on SF are:

   - resource management (synchronisation locks, generic 'closing')
   - HTML tag matching
   - Decimal arithmetic context

Any earlier version used 'suite managers' (partly to avoid confusing the hell 
out of anyone ever exposed to Ruby's concept of blocks), but the 'context 
management' term seems to more clearly describe what the protocol is for.

Cheers,
Nick.

-- 
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] Linux Python linking with G++?

[Martin v. Löwis]

David Abrahams wrote:
>>If there is some library with such objects that happens to get
>>wrapped and dynamically linked into a Python interpreter 
> 
> 
> Whoa there.  How would that ever happen under ordinary circumstances?
> Doesn't Python's makefile control what gets linked to Python?

Not entirely. By extending Modules/Setup (e.g. in the way freeze works),
it is well possible to have additional extension modules linked into the
Python interpreter, extension modules which are not part of the
standard Python distribution.

In fact, before Python supported dynamic loading of extension modules,
this was the *only* way to use non-standard extension modules. You
always had to build your own version of the Python interpreter. I
believe ccpython.cc dates back to these times.

> If there's someone around here who is responsible for this change and
> knows its real rationale, can (s)he please tell me what it is?  If
> not, can we please change things back so Python doesn't get linked to
> the C++ runtime by default?

ccpython.cc and --with-cxx was first published in Python 1.6, and
hasn't changed much since. So for some of you, it has "always"
been there. It was contributed by Geoff Furnish.

What *has* changed now is that the configure test suddenly determines
that you need to link with g++ on Linux if main was compiled with g++.
This was not the case before, but now is (since g++ 3.2 or something).

Regards,
Martin
___
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] Possible context managers in stdlib

[Skip Montanaro]

Ummm...  What's a "context manager"?

Skip
___
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] GCC version compatibility

[Martin v. Löwis]

David Abrahams wrote:
>>When I looked into this problem I saw that configure in fact builds a test
>>executable that included an object file compiled with g++. If the link step
>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>used. Obviously, on my system this test was successful so configure decided
>>to link with gcc. However, minimal changes to the source of the test program
>>caused the link step to fail. It was not obvious to me at all why the latter
>>source code should cause a dependency on the C++ runtime if the original
>>code does not. My conclusion was that this test is fragile and should be
>>skipped. 
> 
> 
> Sounds like it.  I have never understood what the test was really
> checking for since the moment it was first described to me, FWIW.

I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.

>>If Python is built with --with-cxx then it should be linked with CXX
>>as well.
> 
> 
> U betcha.

Wrong. The test was introduced in response to complaints that Python
unnecessarily links with libstdc++ on some Linux systems. On these
Linux systems, it was well possible to build main() with a C++ compiler,
and still link the entire thing with gcc. Since main() doesn't use
any libstdc++ functionality, and since collect2/__main isn't used,
one would indeed expect that linking with CXX is not necessary.

>>(On ELF based Linux/x86, at least.) That leaves me wondering
>>
>> * when is --with-cxx really necessary?
> 
> 
> I think it's plausible that if you set sys.dlopenflags

This has no relationship at all. --with-cxx is much older than
sys.dlopenflags. It is used on systems where main() must be a
C++ program for C++ extension modules to work (e.g. some Linux
systems).

Regards,
Martin
___
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] Linux Python linking with G++?

[Martin v. Löwis]

David Abrahams wrote:
> Unless, of course, I'm missing something.  So if I am missing
> something, what is it?

You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as C++, or else constructors may not work
(and perhaps other things fail as well). The configure option --with-cxx
(documented as "enable C++ support") make Python C++ options work on
such systems. It is automatically enabled if a C++ compiler is found.

There is configure auto-detection for what linker is used when
ccpython.o becomes main().

This is the state of the things as it is. In what way would you like to
see that state changed?

I could personally accept if ccpython and --with-cxx would be dropped
entirely (i.e. deliberately breaking systems which require it); I
just notice the irony of history: ccpython.cc was originally introduced
to better support C++ extension modules - now it might get removed
for the very same reason (to better support C++ extension modules).

Regards,
Martin
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[M.-A. Lemburg]

Nick Coghlan wrote:
> OK, here's some draft documentation using Phillip's context 
> terminology. I think it works very well.
> 
> """
> With Statements and Context Management
> 
> A frequent need in programming is to ensure a particular action is
> taken after a specific section of code has been executed (such as 
> closing a file or releasing a lock). The tool to achieve this in 
> Python is to use the 'with' statement along with the appropriate 
> context manager. Context managers ensure a particular action is taken 
> to establish the context before the contained suite is entered, and a 
> second action to clean up the context when the suite is exited.
> 
> The precise behaviour of the 'with' statement is governed by the
> supplied context manager - an object which supports the context 
> management protocol. This protocol consists of two methods:

May I suggest that you use a different name than "context" for
this ?!

The term "context" is way to broad for the application scopes
that you have in mind here (like e.g. managing a resource
in a multi-threaded application).

The PEP talks about "blocks", which is a much more precise term
for what "with" is going to implement, so I'd suggest to call
these thingies "block managers".

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 08 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Possible context managers in stdlib

[Reinhold Birkenfeld]

Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the moment, if I'm
>> right),
>> > but with context managers, there's certainly room to add some. Of
>> course,
>> > my list is excessive, it's only some ideas I got by flying over the
>> stdlib
>> > docs.
> 
> The PEP contains plenty of examples.  If you're really feeling the need,
> add something to the demo directory.
> 
> For the most part, the applications need to work themselves out over
> time through wikis, individual patch submissions, ASPN recipes,
> third-party apps, etc.  
> 
> The natural evolution of best practices tends to get thwarted by
> prematurely using the standard library to cast a particular solution in
> stone.
> 
> This doesn't preclude individual patches such as a context manager for
> decimal.Context objects.  Each proposal should be considered on its own
> merits rather than as a part of an overall effort to ram a bunch of
> these into the standard library.Over time, plenty of these will
> sprout-up.

As with decorators? Sure, plenty have sprouted up, but delivering them one
release after the feature itself (if the decorators module makes it into 2.5)
seems a little bit like lagging behind -- especially when good and useful
examples exist.

Of course, not all of these in my list are good ideas to implement.

Reinhold

-- 
Mail address is perfectly valid!

___
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] Possible context managers in stdlib

[Michael Chermside]

James Y Knight writes:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager.

Barry Warsaw responds:
> Thinking about the types of code I write over and over again, I think I
> disagree (slightly) with James about the global state thing.  While I
> agree that 'with redirected_stdio' isn't too useful in the face of
> print>>, I very often have to write try/finally protections around
> temporary settings of the cwd, the umask, and other global process
> values.  I'd love to see cm's for those constructs in the stdlib.

I agree with Barry. Not only should they be in the stdlib, but they
should have very clear warnings in their docstrings and other documentation
that state that they are ONLY safe to use in single-threaded programs.

This achieves two things: it makes them available to those who need
them (not everyone uses threads!), and it rather forcefully makes the
point that it's NOT usually a good idea to modify global state info in
a context manager because doing so is not generally threadsafe.

-- Michael Chermside

___
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] Possible context managers in stdlib

[Raymond Hettinger]

> > I compiled a list of some possible new context managers that could
be
> > added to the stdlib. Introducing a new feature should IMO also show
> > usage of it in the distribution itself. That wasn't done with
> > decorators (a decorators module is compiled at the moment, if I'm
> right),
> > but with context managers, there's certainly room to add some. Of
> course,
> > my list is excessive, it's only some ideas I got by flying over the
> stdlib
> > docs.

The PEP contains plenty of examples.  If you're really feeling the need,
add something to the demo directory.

For the most part, the applications need to work themselves out over
time through wikis, individual patch submissions, ASPN recipes,
third-party apps, etc.  

The natural evolution of best practices tends to get thwarted by
prematurely using the standard library to cast a particular solution in
stone.

This doesn't preclude individual patches such as a context manager for
decimal.Context objects.  Each proposal should be considered on its own
merits rather than as a part of an overall effort to ram a bunch of
these into the standard library.Over time, plenty of these will
sprout-up.



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] Possible context managers in stdlib

[Reinhold Birkenfeld]

Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>with sys.trace
> 
> Note that it's currently not possible to inspect the trace/profile hooks 
> from Python code, only from C, so that might be, um, interesting to implement.

That was beyond my short view... if it can't be implemented, it won't.

>>* pprint: with pprint.printer (used for print)
> 
> Interesting; I'm not sure if I like it.
> 
>>* os: with os.current_directory
> 
> What does this do?  Oh, I get it.  The name's not very obvious.  I would've 
> expected a more imperative name, something like 'with os.setcwd()' or 'with 
> os.pushdir()'.

I didn't think about the names too long. ;)

>>   with os.modified_env
>>   with os.umask/uid/gid etc.
> 
> Yeah, again I would expect more verbish names, but these are at least 
> easier to grasp than current_directory was.

Names can be found, of course.

>>* curses: with curses.wrapper
>>with logging.Logger
>>* tty: with tty.raw
>>with tty.cbreak
>>* cgitb: with cgitb.enabled
> 
> What do these do?

curses: curses.wrapper currently is a function which restores sane terminal
settings after the curses program bails out. It could be a context manager too.
Similar is tty.raw and tty.cbreak. These switch terminal modes, and in case
of an uncaught exception the terminal will stay in this state. Context managers
would restore the "sane" mode on exit.

logging.Logger: hm, I didn't think about that properly.
cgitb: enables or disables the full traceback view (Ok, it wouldn't be so 
useful).

Reinhold


-- 
Mail address is perfectly valid!

___
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] Possible context managers in stdlib

[Barry Warsaw]

On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:

> I compiled a list of some possible new context managers that could be
> added to the stdlib.

I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
purposes.  Keep the list short and sweet.  Also, I'd like to see some
higher-level cm's in the mix, perhaps implementing concepts like Java's
synchronized (perhaps even being named 'with synchronization').

Thinking about the types of code I write over and over again, I think I
disagree (slightly) with James about the global state thing.  While I
agree that 'with redirected_stdio' isn't too useful in the face of
print>>, I very often have to write try/finally protections around
temporary settings of the cwd, the umask, and other global process
values.  I'd love to see cm's for those constructs in the stdlib.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Possible context managers in stdlib

[James Y Knight]

On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
> I think having basic context managers in a stdlib module that we know
> for a fact that will be handy is a good idea.  We should keep the list
> short and poignant, but we should have something for people to work
> off of.  The ones I like below for a 'context' module are:
>
>> * builtins: with open/file
>> * sys: with sys.redirected_std[in|out|err]
>> * decimal: with decimal.Context
>> * os: with os.current_directory
>> * mutex: with mutexobj
>> * threading: with threading.Lock
>>  with threading.Condition
>>  with threading.Event
>> * bz2/zipfile/tarfile: with ...open

It is a really bad idea to codify the practice of modifying non- 
threadlocal global state like sys.std[in|out|err] and current  
directory with a context manager. A user can do it to themselves now,  
true, but by putting a context manager for it in the stdlib, you make  
it look like it'd be a local modification when it is not. I can only  
see confusion resulting from this. Users will inevitably try to use  
it like
   with sys.redirected_stderr(f):
 print "hello"
 print "there"
instead of explicitly writing to f with print>> or write(). And that  
is just a terribly bad idea. It looks pretty, yes, but unless  
stdinouterr are made thread-local, it's just asking for trouble.

James
___
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] Possible context managers in stdlib

[Phillip J. Eby]

At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>with sys.trace

Note that it's currently not possible to inspect the trace/profile hooks 
from Python code, only from C, so that might be, um, interesting to implement.

>* pprint: with pprint.printer (used for print)

Interesting; I'm not sure if I like it.

>* os: with os.current_directory

What does this do?  Oh, I get it.  The name's not very obvious.  I would've 
expected a more imperative name, something like 'with os.setcwd()' or 'with 
os.pushdir()'.

>   with os.modified_env
>   with os.umask/uid/gid etc.

Yeah, again I would expect more verbish names, but these are at least 
easier to grasp than current_directory was.


>* curses: with curses.wrapper
>with logging.Logger
>* tty: with tty.raw
>with tty.cbreak
>* cgitb: with cgitb.enabled

What do these do?

___
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] checklist for filing a bug

[Raymond Hettinger]

> In order to lower the barrier for reporting bugs, writing patches, and
> handling CVS commits, I am writing up checklists for each and I will
> put them up on python.org.

-0 on the checklists.  I don't think existing "barriers" are high at
all.  The entries may be variously regarded as codifying common sense or
listing nice-to-haves instead of must haves.  Based on the SF activity
over the last few years, I conclude that the checklists attempt to solve
a non-problem (or rather a very minor irritant).

Yes, it would be great if everyone searched SF for all previous related
bug reports, and spent time isolating/reproducing the cause, and if all
bug reports were reproducible 100% of the time, and if someone wrote a
unittest for it.  Heck, it would be nicer still if they debugged the
exact problem and fixed it ;-)  However, in real life, we get plenty of
useful reports that don't fit one or all of those criteria.  I don't
want to unnecessarily raise the bar and not have someone report a
potentially valid bug.

IMO, the proposal is administrivia that doesn't add value and possibly
makes things worse (by causing some folks to not go through the hassle
of filing a report).


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] Possible context managers in stdlib

[Brett Cannon]

On 7/8/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I compiled a list of some possible new context managers that could be
> added to the stdlib. Introducing a new feature should IMO also show
> usage of it in the distribution itself. That wasn't done with
> decorators (a decorators module is compiled at the moment, if I'm right),
> but with context managers, there's certainly room to add some. Of course,
> my list is excessive, it's only some ideas I got by flying over the stdlib
> docs.
> 

I think that is a good point about decorators.  While none of us
obviously had extensive experience with decorators when they went into
the language we at least knew of a couple use cases that would have
been handy and it probably would have been good to have examples for
people to work off of.  I bet iterators have gotten more play thanks
to itertools and all of the built-ins that work with them.

I think having basic context managers in a stdlib module that we know
for a fact that will be handy is a good idea.  We should keep the list
short and poignant, but we should have something for people to work
off of.  The ones I like below for a 'context' module are:

> * builtins: with open/file
> * sys: with sys.redirected_std[in|out|err]
> * decimal: with decimal.Context
> * os: with os.current_directory
> * mutex: with mutexobj
> * threading: with threading.Lock
>  with threading.Condition
>  with threading.Event
> * bz2/zipfile/tarfile: with ...open

-Brett
___
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] Possible context managers in stdlib

[Reinhold Birkenfeld]

Hi,

I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context managers, there's certainly room to add some. Of course,
my list is excessive, it's only some ideas I got by flying over the stdlib
docs.

* builtins: with open/file
* sys: with sys.redirected_std[in|out|err]
   with sys.trace
   with sys.excepthook
* warnings: with warnings.filter
* pprint: with pprint.printer (used for print)
* codecs: with codecs.open
  with codecs.EncodedFile
* decimal: with decimal.Context
* os: with os.current_directory
  with os.modified_env
  with os.umask/uid/gid etc.
  with os.popen
  with os.tmpfile
* subprocess: with subprocess.Popen
* mutex: with mutexobj
* curses: with curses.wrapper
* tempfile: with tempfile.[Named]TemporaryFile
etc.
* locale: with locale.differentlocale
* logging: with logging.ignored
   with logging.Logger
* signal: with signal.handler
* socket: with socket.socket
* threading: with threading.Lock
 with threading.Condition
 with threading.Event
* mmap: with mmap.mmap
* bz2/zipfile/tarfile: with ...open
* dl: with dl.open
* tty: with tty.raw
   with tty.cbreak
* cgitb: with cgitb.enabled
* urllib/urllib2: with urllib.urlopen
  etc.
* httplib: with httplib.HTTPConnection
* ftplib: with ftplib.FTP
* poplib: with poplib.POP3
* imaplib: with imaplib.IMAP4
* nttplib: with nntplib.NNTP
* smtplib: with smtplib.SMTP
* telnetlib: with telnetlib.Telnet
* xmlrpclib: with xmlrpclib.ServerProxy

Reinhold

-- 
Mail address is perfectly valid!

___
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Terry Reedy]

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Phillip J. Eby wrote:
>> I suggest changing this to something like this:
>>
>> class tag(object):
>> def __init__(self,name):
>> self.name = name
>> def __enter__(self):
>> print "<%s>" % name
>> def __exit__(self):
>> print "" % name
>>
>> with tag('html'):
>> # ... etc.
>>
>> So that it's obvious where the implementation is coming from.
>> Otherwise, it looks altogether too magical.
>
> Done - included in the latest version on SF. [1]

Would this also work as a decorated generator?
(If I have understood correctly, something like..)

@contextmanager
def tag(name)
   print "<%s>" % name
   yield None
   print "" % name

If so, I suggest putting in both versions to make the correspondence clear.

To whoever invented this example: thanks.  It rang a bell with me so I 
could see this as a generally usefully feature rather than a specialized 
(though for some, important) 'close resource' feature.

The particularly neat thing is that it converts the indent-dedent method of 
showing structure to the alternative matched-fences method.   This is 
certainly not limited to HTML generation.

Terry J. Reedy



___
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] Chaining try statements: eltry?

[Ron Adam]

Thomas Lotze wrote:

> Ron Adam <[EMAIL PROTECTED]> wrote:

>>3. In a while loop, it's a value test, where the else block gets 
>>executed if the while condition evaluates as false, the while block
>>may  or may not execute. You still need a flag to test for that.
> 
> 
> You're effectively arguing for do...while, right?

Not arguing anything.  Do-whiles are a flow control issue rather than a 
flow testing issue.   A differnt problem.

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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Terry Reedy]

"Walter Dörwald" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>x = blist()
>x(1)
>with blist(x) as x:
>x(2)
>with blist(x) as x:
>   x(3)
>x(4)
>x(5)

>This would create the list:
>[1, [2, [3], 4], 5]

>With the current version of PEP 343, we would either have to use
>different variable names on each level

To me, different  names on each level -- x0, x1, x2, ... would be clearer 
and preferable, so I would know right off which level something was being 
put at.

This is no different from using differnt iteration variables -- i,j,k; or 
i1, i2, i3; etc -- with nested loops.  In both cases, you can delete the 
unneeded var if you really care and will not be using them again for 
another nested construct.

Terry J. Reedy



___
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] Chaining try statements: eltry?

[Ron Adam]

Michael Hudson wrote:
> Ron Adam <[EMAIL PROTECTED]> writes:
> 
> 
>>Guido van Rossum wrote:
>>
>>
>>>I even wonder if else-clauses on for/while were a good idea. (The one
>>>on try is definitely a good idea since the use case is quite frequent
>>>and only clumsily handled otherwise; the use cases for else on
>>>for/while are less convincing IMO.)
>>
>>
>>I'm +1 on removing the else from the loops myself.
> 
> 
> ... in Python 3000, I hope you meant to qualify that with.

Yes, that's what I meant.


> 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] Chaining try statements: eltry?

[Anthony Baxter]

On Friday 08 July 2005 04:54, Guido van Rossum wrote:
> How would a PEP to *remove* this feature fare today?

I'd very much prefer that we kept them. I find it a useful
way to group the behaviour of the looping - this bit is
the normal loop, and this bit at the end is when the loop
fails/is exhausted. This is obviously for when you use it in 
a loop where you're looking for a certain result. And yes, 
you can do something similar with try/except, but I find 
that ugly - 'break' is the natural way to get out of a loop, 
not 'raise'. I find using exceptions in this way to be a
sort of horrible goto-hack, and makes the code hard on the
brain. 

(obdisclaimer: for/else gets a mention in my OSCON python
tutorial, so I'd appreciate it if you _don't_ rip it out
in the next month )

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Chaining try statements: eltry?

[Scott David Daniels]

[EMAIL PROTECTED] wrote:
>... if Py3k ever happens, I'd hope that it would be the *one* Python
> to use -- too many incompatibilities would probably mean *two* 
> Pythons fighting each other).

A caduceus to heal software problems?

 http://www.pantheon.org/articles/c/caduceus.html

--Scott David Daniels
[EMAIL PROTECTED]

___
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] GCC version compatibility

[David Abrahams]

[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic.  I think this is
crucial to the way they package and deliver Python]

Christoph Ludwig <[EMAIL PROTECTED]> writes:

> On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote:
>> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> 
>> > David Abrahams wrote:
>> >> I'm wondering if there has been a well-known recent change either in 
>> >> Python
>> >> or GCC that would account for these new reports.  Any relevant
>> >> information would be appreciated.
> [...]
>> > Python is linked with g++ if configure thinks this is necessary
>> 
>> Right.  The question is, when should configure "think it's necessary?"
>
> Just to add to the confusion... I encountered the case that configure decided
> to use gcc for linking but it should have used g++. (It is Python 
> PR #1189330 . This was on a x86 Linux system with
> g++ 3.4.2.)
>
> Background: The description of --with-cxx in the README of the
> Python 2.4.1 source distribution made me think that I need to
> configure my Python installation with
> --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++
> extensions built with this compiler. (That was possibly a
> misunderstanding on my part, 

AFAICT, yes.

> but Python should build with this option anyway.)
>
> configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when
> linking the python executable due to an unresolved reference to
> __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC
> to finish the build of Python.
>
> When I looked into this problem I saw that configure in fact builds a test
> executable that included an object file compiled with g++. If the link step
> with gcc succeeds then LINKCC is set as above, otherwise CXX is
> used. Obviously, on my system this test was successful so configure decided
> to link with gcc. However, minimal changes to the source of the test program
> caused the link step to fail. It was not obvious to me at all why the latter
> source code should cause a dependency on the C++ runtime if the original
> code does not. My conclusion was that this test is fragile and should be
> skipped. 

Sounds like it.  I have never understood what the test was really
checking for since the moment it was first described to me, FWIW.

> If Python is built with --with-cxx then it should be linked with CXX
> as well.

U betcha.

> I gather from posts on the Boost mailing lists that you can import
> Boost.Python extensions even if Python was configured
> --without-cxx. 

Yes, all the tests are passing that way.

> (On ELF based Linux/x86, at least.) That leaves me wondering
>
>  * when is --with-cxx really necessary?

I think it's plausible that if you set sys.dlopenflags to share
symbols it *might* end up being necessary, but IIRC Ralf does use
sys.dlopenflags with a standard build of Python (no
--with-cxx)... right, Ralf?

>  * what happens if I import extensions built with different g++ versions? Will
>there be a conflict between the different versions of libstdc++ those
>extensions depend on?

Not unless you set sys.dlopenflags to share symbols.  

It's conceivable that they might conflict through their shared use of
libboost_python.so, but I think you have to accept that an extension
module and the libboost_python.so it is linked with have to be built
with compatible ABIs anyway.  So in that case you may need to make
sure each group of extensions built with a given ABI use their own
libboost_python.so (or just link statically to libboost_python.a if
you don't need cross-module conversions).

HTH,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.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] Adding the 'path' module (was Re: Some RFE for review)

[Thomas Heller]

Neil Hodgson <[EMAIL PROTECTED]> writes:

> Thomas Heller:
>
>> OTOH, I once had a bug report from a py2exe user who complained that the
>> program didn't start when installed in a path with japanese characters
>> on it.  I tried this out, the bug existed (and still exists), but I was
>> astonished how many programs behaved the same: On a PC with english
>> language settings, you cannot start WinZip or Acrobat Reader (to give
>> just some examples) on a .zip or .pdf file contained in such a
>> directory.
>
>Much of the time these sorts of bugs don't make themselves too hard
> to live with because  most non-ASCII names that any user encounters
> are still in the user's locale and so get mapped by Windows.

> It can be a lot of work supporting wide file names. I have just added
> wide file name support to my editor, SciTE, for the second time and am
> about to rip it out again as it complicates too much code for too few
> beneficiaries. (I want one executable for both Windows NT+ and 9x, so
> wide file names has to be a runtime choice leading to maybe 50 new
> branches in the code).

In python, the basic support for unicode file and pathnames is already
there.  No problem to open a file named
u'\u5b66\u6821\u30c7\u30fc\\blah.py on WinXP with german locale.

But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
this file as module.  Internally Python\import.c converts everything to
strings.  I started to refactor import.c to work with PyStringObjects
instead of char buffers as a first step - PyUnicodeObjects could have
been added later, but I gave up because there seems absolute zero
interest in it.

Ok - it makes no sense to have Python modules in directories with these
filenames, but Python (especially when frozen or py2exe'd) itself could
easily live itself in such a directory.

>If returning a mixture of unicode and narrow strings from
> os.listdir is the right thing to do then maybe it better for sys.argv
> and os.environ to also be mixtures. In patch #1231336 I added parallel
> attributes, sys.argvu and os.environu to hold unicode versions of this
> information. The alternative, placing unicode items in the existing
> attributes minimises API size.
>
>One question here is whether unicode items should be added only
> when the element is outside the user's locale (the CP_ACP code page)
> or whenever the item is outside ASCII. The former is more similar to
> existing behaviour but the latter is safer as it makes it harder to
> implicitly treat the data as being in an incorrect encoding.

I can't judge on this - but it's easy to experiment with it, even in
current Python releases since sys.argvu, os.environu can also be
provided by extension modules.

But thanks that you care about this stuff - I'm a little bit worried
because all the other folks seem to think everything's ok (?).

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

Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343

[Nick Coghlan]

Phillip J. Eby wrote:
> I suggest changing this to something like this:
> 
> class tag(object):
> def __init__(self,name):
> self.name = name
> def __enter__(self):
> print "<%s>" % name
> def __exit__(self):
> print "" % name
> 
> with tag('html'):
> # ... etc.
> 
> So that it's obvious where the implementation is coming from.  
> Otherwise, it looks altogether too magical.

Done - included in the latest version on SF. [1]

> Also, the posted draft doesn't explain what happens to the __enter__ 
> return value, either in a literal sense or in the sense of where it fits 
> in the overall concept of context management.

I've tried to clarify this by showing usage of the closing() context manager.

Cheers,
Nick.

[1] http://www.python.org/sf/1234057

-- 
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] checklist for filing a bug

[Skip Montanaro]

Brett> #. Gather important information
Brett> Info such as Python version, operating system version, etc.;
Brett> anything that might have influenced the code that lead to the
Brett> bug.

I'd change this to something more explicit:

# Gather important information
  * Python version
  * Operating system and version
  * Third-party modules installed/involved
  * Presence of user-written extension modules
  ... add your own faves here ...

I doubt that a wet-behind-the-ears Python programmer who only knows Windows
is likely to understand that Windows XP Home Edition (vs. CentOS 4) might be
a factor in the emergence of the bug.

Skip

___
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:

> OTOH, I once had a bug report from a py2exe user who complained that the
> program didn't start when installed in a path with japanese characters
> on it.  I tried this out, the bug existed (and still exists), but I was
> astonished how many programs behaved the same: On a PC with english
> language settings, you cannot start WinZip or Acrobat Reader (to give
> just some examples) on a .zip or .pdf file contained in such a
> directory.

   Much of the time these sorts of bugs don't make themselves too hard
to live with because  most non-ASCII names that any user encounters
are still in the user's locale and so get mapped by Windows. It can be
a lot of work supporting wide file names. I have just added wide file
name support to my editor, SciTE, for the second time and am about to
rip it out again as it complicates too much code for too few
beneficiaries. (I want one executable for both Windows NT+ and 9x, so
wide file names has to be a runtime choice leading to maybe 50 new
branches in the code).

   If returning a mixture of unicode and narrow strings from
os.listdir is the right thing to do then maybe it better for sys.argv
and os.environ to also be mixtures. In patch #1231336 I added parallel
attributes, sys.argvu and os.environu to hold unicode versions of this
information. The alternative, placing unicode items in the existing
attributes minimises API size.

   One question here is whether unicode items should be added only
when the element is outside the user's locale (the CP_ACP code page)
or whenever the item is outside ASCII. The former is more similar to
existing behaviour but the latter is safer as it makes it harder to
implicitly treat the data as being in an incorrect encoding.

   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

Re: [Python-Dev] Chaining try statements: eltry?

[Michael Hudson]

Ron Adam <[EMAIL PROTECTED]> writes:

> Guido van Rossum wrote:
>
>> I even wonder if else-clauses on for/while were a good idea. (The one
>> on try is definitely a good idea since the use case is quite frequent
>> and only clumsily handled otherwise; the use cases for else on
>> for/while are less convincing IMO.)
>
>
> I'm +1 on removing the else from the loops myself.

... in Python 3000, I hope you meant to qualify that with.

Cheers,
mwh

-- 
   wait when was the earth created?
   just look at the expiration date
   it's on the bottom, under the ice cap
-- 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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Michael Hudson]

Walter Dörwald <[EMAIL PROTECTED]> writes:

> Michael Hudson wrote:
>
>> Walter Dörwald <[EMAIL PROTECTED]> writes:
>> [...]
>>>I.e. will VAR still exist after the end of the block with its value
>>>the return value of __enter__() or will it revert to the previous
>>>value (if any)?
>> 
>> Eh, no.  Where would you store the old value?
>
> I don't know, where does:
>
>  >>> x = 42
>  >>> "".join(chr(x) for x in xrange(10))
> '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t'
>  >>> x
> 42
>
> store it?

In a new frame, AIUI.

You'll get a different answer for a list comprehension, as I'm sure
you know.

Cheers,
mwh

-- 
  I sense much distrust in you.  Distrust leads to cynicism, cynicism
  leads to bitterness, bitterness leads to the Awareness Of True
  Reality which is referred to by those-who-lack-enlightenment as
  "paranoia".  I approve.-- David P. Murphy, alt.sysadmin.recovery
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Walter Dörwald]

Michael Hudson wrote:

> Walter Dörwald <[EMAIL PROTECTED]> writes:
> [...]
>>I.e. will VAR still exist after the end of the block with its value
>>the return value of __enter__() or will it revert to the previous
>>value (if any)?
> 
> Eh, no.  Where would you store the old value?

I don't know, where does:

 >>> x = 42
 >>> "".join(chr(x) for x in xrange(10))
'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t'
 >>> x
42

store it?

 > [...]

Bye,
Walter Dörwald
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Michael Hudson]

Walter Dörwald <[EMAIL PROTECTED]> writes:

> Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>
 +1 on @contextmanager
>>
>> +1.
>>
>> [__enter__, __exit__]
>>
> These names should be changed to __beginwith__ and __endwith__.
>
>>
>> -1.  The PEP has had an extensive review period and several
>> alternatives were discussed and rejected. These names are clear, they
>> *do* match, and as Fred says the __*__ namespace has lots of room.
>>
>> Also, the PEP was accepted with these names. Now, if it was accepted
>> with a major flaw or some semantics left unspecified,
>
> What is still unspecified (or at least not explicitely mentioned) in  
> the PEP is the lifetime of VAR in:
>
>  with EXPR as VAR:
>  BLOCK
>
> Does VAR overwrite or shadow any previous values of VAR? 

Yup!  Or at least in my half-an-implementation, that's what happens.

(PEP 343 is a lot harder to implement then you might think, btw -- the
stack discipline around finally: statements is a bit mind-bending).

> I.e. will VAR still exist after the end of the block with its value
> the return value of __enter__() or will it revert to the previous
> value (if any)?

Eh, no.  Where would you store the old value?

> I'd prefer the later although interpreting the translation of
>
>  with EXPR as VAR:
>  BLOCK
>
> into
>
>  abc = EXPR
>  exc = (None, None, None)
>  VAR = abc.__enter__()
>  try:
>  try:
>  BLOCK
>  except:
>  exc = sys.exc_info()
>  raise
>  finally:
>  abc.__exit__(*exc)
>
>
> literally would indicate the former.

Please continue to interpret it like that :)

Cheers,
mwh

-- 
  > Why are we talking about bricks and concrete in a lisp newsgroup?
  After long experiment it was found preferable to talking about why
  Lisp is slower than C++...
-- Duane Rettig & Tim Bradshaw, comp.lang.lisp
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Walter Dörwald]

Guido van Rossum wrote:
> On 7/7/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> 
>>What is still unspecified (or at least not explicitely mentioned) in
>>the PEP is the lifetime of VAR in:
>>
>> with EXPR as VAR:
>> BLOCK
> 
> It is specified well enough IMO -- you're supposed to take the
> translation into basic Python seriously. That translation specifies a
> simple assignment to VAR, and that's what I meant (and what I'm sure
> most folks understood). IOW VAR lives in the surrounding scope,
> overwrites a previous value, and survives past the with-statement
> (unless it is set inside of course).

Are there use cases for both variants?

If VAR would live only until the end of the with block, this would give 
us a nice way of generating nested data structures:

class blist(list):
def __init__(self, parent=None):
   if parent:
  parent.append(self)
   list.__init__(self)

def __enter__(self):
   return self

def __call__(self, *items):
   self.extend(items)
   return self

x = blist()
x(1)
with blist(x) as x:
x(2)
with blist(x) as x:
   x(3)
x(4)
x(5)

This would create the list:
[1, [2, [3], 4], 5]

With the current version of PEP 343, we would either have to use 
different variable names on each level or use a global stack where 
__enter__() and __exit__() push and pop values.

Bye,
Walter Dörwald
___
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] checklist for filing a bug

[Tadeusz Andrzej Kadłubowski]

Thus wrote Brett Cannon:

How about:

> #. Report the bug on SourceForge_

  Make sure your bug hasn't been reported many times already.

> Create a new tracker item, filling out the ``Category`` and ``Group``
> fields.  Do not set the ``Assigned To`` or ``Priority`` fields.  Upload  
> your code snippet as a file and make sure to click the ``Upload`` button! 

-- 
tadeusz andrzej kadłubowski
___
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] Chaining try statements: eltry?

[Thomas Lotze]

Ron Adam <[EMAIL PROTECTED]> wrote:

> 1. With an if, if you think in terms of flow testing you get the same 
> results as if you look at it in in terms of value testing.  Either the
> if-block will execute or the else-block will, but never any part of
> one  and then the other.  A binary solution to a binary problem.
> 
> 2. With a try, It's a value test for no exception. Or you could
> consider  it flow test for the try block completing.

You might also look at it like this: There's a correspondence between
the if and try statements with if/elif corresponding to except and else
having the same meaning in both cases. With the exception of the try
suite that sets the stage for exception handlers, both statements give
you a set of branches (if/elif/else suites and execpt/else suites,
resp.) exactly one of which will execute.

Which is one of the reasons why I came to think of my proposal starting
this thread of being half-baked at best...

> 3. In a while loop, it's a value test, where the else block gets 
> executed if the while condition evaluates as false, the while block
> may  or may not execute. You still need a flag to test for that.

You're effectively arguing for do...while, right?

> 4. In a for loop, it's a test of the iterator completing and
> generating  a StopIteration exception.  Which is somewhat implicit. 
> The for block  may or may not execute.

This is something different IMO. You don't want to model condition
testing, you want to act on a set of values which may or may not be
empty. That's why I think you actually want the StopIteration stuff to
be implicit.

-- 

Viele Grüße,
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

Re: [Python-Dev] Chaining try statements: eltry?

[Nick Coghlan]

Phillip J. Eby wrote:
> At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
>>I also suspect that if they weren't in the language already, a PEP to
>>introduce them would fail, because
>>
>>still_looking = True
>>some loop:
>>if found it:
>>still_looking = False
>>break
>>if still_looking:
>># what would have been in the "else" clause
>>
>>is clear and easy to write without it.
> 
> 
> *shudder* Okay, you just convinced me.  "Else" should stay, because the 
> above is much less readable and writable!

I think Aahz's point is a good one - conditional flow control can be most 
clearly represented using try blocks:

   class BreakException(Exception): pass

   try:
   some loop:
   if found it:
   raise BreakException
   except BreakException:
   pass
   else:
   # What would have been in the else clause

Defining 'else' on loops as short-hand for the above may make the intent of 
the clauses clearer (that is, for/else and while/else are more closely related 
to try statements than they are to if statements).

Regards,
Nick.

-- 
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] 'With' context documentation draft (was Re: Terminology for PEP 343

[Guido van Rossum]

On 7/7/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> What is still unspecified (or at least not explicitely mentioned) in
> the PEP is the lifetime of VAR in:
> 
>  with EXPR as VAR:
>  BLOCK

It is specified well enough IMO -- you're supposed to take the
translation into basic Python seriously. That translation specifies a
simple assignment to VAR, and that's what I meant (and what I'm sure
most folks understood). IOW VAR lives in the surrounding scope,
overwrites a previous value, and survives past the with-statement
(unless it is set inside of course).

-- 
--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] Chaining try statements: eltry?

[[EMAIL PROTECTED]]

> > [Guido, on {for,while}/else]
> 
> How would a PEP to *remove* this feature fare today?

-1.

It took me a while (actually a *long* while) to start using else
clauses in loops, but I've learned to love them. Although there
aren't that many use cases, they make the code more readable (and
writable) where they apply.

For me, for/else and while/else didn't make Python harder to
learn; I just ignored them for some years.

And I'm horrified at the thought of having to go look for all
occurrences if they were removed (if Py3k ever happens, I'd hope
that it would be the *one* Python to use -- too many
incompatibilities would probably mean *two* Pythons fighting each
other).

-- 
Christian Tanzerhttp://www.c-tanzer.at/

___
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