Is there any kind of internal file descriptor counter that can be
queried to debug issues with leaking resources?
It can be used in tests to check that all tests are finish with 0
It will be very useful while porting Python applications from Unix to
Windows. Unix is more tolerant to open files and can overwrite them
and do other nasty things. See the thread from comment #17 -
https://bugs.edge.launchpad.net/dulwich/+bug/557585/ - there is an
example of mmap that starts holding file descriptor somewhere long
before an error occurs. How could one debug this?
Right now I have to use FileMon. It includes information about
operated filenames, but no info about source code where this happens.
It will be nice to have some kind of counter with filename information
inside Python, so that it can be possible to get the full log of
events without manually messing with external system-specific tools
I know the issue has been discussed several times already, however I couldn't find any reasonable explanation of its strange behaviour. The main problem with 'hasattr' function is that is swallows all exceptions derived from Exception class. It's a good thing that it doesn't do that with BaseException as it was fixed not a long time ago, but it's definitely not enough.
First of all, this behaviour of 'hasattr' contradicts with the very core principle of python: "Errors should never pass silently." And since 'hasattr' function is in builtins module and is a widely used function it impacts the whole language.
Secondly, take a look at the following:
>>> class Test:
... def attr(self):
>>> hasattr(Test(), 'attr')
There can be any exception instead of KeyError in the above snippet of code, but this small example shows how 'hasattr': misleadingly breaks the code logic (1) and masks bug (2). And that's the simplest possible example, there are much more in real life.
While (1) is maybe acceptable for someone, there is no excuse for the (2). Moreover, current 'hasattr' behaviour tremendously complicates use of '__getattribute__' magic. And forget about importlib magic with LazyImports, one 'hasattr' ruins everything by catching ImportError.
1) I propose to change 'hasattr' behaviour in Python 3, making it to swallow only AttributeError exceptions (exactly like 'getattr'). Probably, Python 3.2 release is our last chance.
2) If you afraid that this new behaviour will break too much python 2 code converted with 2to3, we can introduce another 'hasattr' function defined in 2to3 module itself, and make it imported automatically in all files passed through 2to3 transformation pipeline. This new function will mimic 'hasattr' behaviour from python 2 and converted code should work as expected.
Since the recent history of my two Windows buildbots has turned ugly,
I figured I'd mention that they both (XP and Windows 7) have started
generating quite a few GUI C++ RTL runtime pop-up assertions, which
has been throwing a wrench into things until they get manually
cleared. I first noticed them Sunday night but they were probably
there 24-48 hours at that point. These are R6034 "An application has
made an attempt to load the C runtime library incorrectly"
I glanced through recent commits and I don't think I see anything
obviously related but was wondering if anyone who might have been
committing changes in the past few days might have an thought? The
source filename is truncated in the dialog (what genius at MS thought
that would be the one field worth truncating?!) so I am not absolutely
sure if they are limited to a specific branch or not.
I've thrown on an autoit script to try to automatically acknowledge
these dialogs so hopefully the affected test runs will just fail
rather than timing out and blocking later runs.
Hello fellow Pythoneers and Pythonistas,
I'm very happy to announce the release of Python 2.6.6. A truly impressive
number of bugs have been fixed since Python 2.6.5. Source code and Windows
installers for Python 2.6.6 are now available here:
The full details of everything that's changed is available in the NEWS file:
Python 2.6.6 marks the end of regular maintenance releases for the Python 2.6
series. From now until October 2013, only security related, source-only
releases of Python 2.6 will be made available. After that date, Python 2.6
will no longer be supported, even for security bugs.
My deepest appreciation go out to everyone who has helped contribute fixes
great and small, and much testing and bug tracker gardening for Python 2.6.6.
(on behalf of the Python development community)
On Sun, 29 Aug 2010 22:56:56 +0200 (CEST)
giampaolo.rodola <python-checkins(a)python.org> wrote:
> + with self.assertRaises(IOError) as err:
> + ssl.wrap_socket(socket.socket(), certfile=WRONGCERT)
> + self.assertEqual(err.errno, errno.ENOENT)
The assertEqual will never get executed since the previous line raises.
> + with self.assertRaises(IOError) as err:
> + ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, keyfile=WRONGCERT)
> + self.assertEqual(err.errno, errno.ENOENT)
I want to bring up a "forbidden" topic, however, I believe I have some strong points.
There are many ways of doing asynchronous programming in Python. Multiprocessing,
Threads, Greenlets, Deferred Object (Callbacks) and Coroutines. The latter is quite
a new approach, but it gets more and more attention. What's really fascinating about
coroutines, is that a code flow of a program using them reads naturally and straight.
Callbacks break that code flow making it much harder to read and understand, threads
don't work good in Python, and greenlets... greenlets are too magical, and,
So, coroutines are good, and that is proved by a pleiad of new frameworks that utilize
them: Monocle, cogen, and many others. However, coroutines in python are a bit
incomplete. There is no standard way of returning a result value, making coroutine
Let's take a look at the following example:
... def method1():
... # some computation
... return result
... def method2():
... data = yield memcache.get(...)
... # some computation
... # and now, the most interesting point. Time to return a result.
... # Pick the prettiest line:
... # yield Return(result)
... # return_ (result)
... # raise StopIteration(result)
As you can see, there is no way of simple abstraction of coroutines. How nice is
the 'yield' syntax here, that clearly marks async call, and how ugly is the return
code. Speaking about large amounts of a code like the above it's hard to maintain
and refactor it. Adding one yield statement to some generically decorated handler
will force you to fix all returns and vice versa. Moreover, lack of proper return
protocol complicates the underlying code.
The very straightforward solution was proposed in PEP 380, and here it is a good
place to say, that PEP 380 is not all about returns. It's all about new 'yield from'
statement, and the new return syntax for coroutine is the very small part of it.
However, in any currently existing framework it is possible to implement 'yield from'
statement (with smth like yield From(...)), but there's absolutely no way to correct
the return problem, as it raises SyntaxError which is impossible to catch. Therefore,
I think that we can consider the returns problem apart from PEP 380.
Proposed change uses the same type of approach as was introduced in PEP 380, but in
a slightly different way. Instead of attaching the return value to StopIteration
exception, we can introduce another one, let's call it GeneratorReturn (derived from
BaseException). Still easy to use it in frameworks, but make it impossible to break
things unintentionally. For example, it will protect us from cases like the
... def test():
... for i in range(10):
... yield i
... return 10
In the above, GeneratorReturn error will be propagated stopping the program execution.
Strictly speaking, the proposed change is just alters the current Python behaviour,
making the 'return value' statement raise catchable error (instead of SyntaxError.)
Speaking about PEP 3003. I'm pretty much sure that the idea behind moratorium on
serious language changes was to give alternative python interpreters a chance to
catch up Python 3. Well, the proposed is a very small change in CPython, just few
lines of code. It doesn't change grammar or AST tree structure, and it is fully
backwards compatible. I've looked at the PyPy code and found that the change is
*very* easy to port there, and I'm certain that the situation is the same for Jython
and IronPython. (If this new feature would be the only problem why we don't see
Jython or PyPy supporting 3.2 version we all would be more than happy.) Given all
that, I think PEP 3003 is inapplicable to this proposal.
- The change on the interpreter side is tiny (reducing the entropy in symtable.c!)
- No affect on grammar or AST structure.
- Easy to port to other interpreters.
- Fully backward compatible.
- On the very basic level it will change current behaviour from raising an
uncatchable error to raising a catchable one. Nobody will be confused.
- Another key feature of Python 3, that will probably encourage people to
- Will make coroutines more attractive and stimulate the rise of new frameworks
and development of new ones.
- One way of doing things. The same interface in frameworks, code in coroutines
look almost the same as in subroutines but with yields. Make coroutines protocol
If we decide to postpone this feature till Python 3.3, than we'll push it all back
for *years*. The change is tiny, but it means really a lot. Those who tried to
work with coroutines will understand me. Let's at least consider it.
PS I'm attaching a patch to the letter; it's far from ideal state, but contains the
GeneratorReturn exception, code to raise it and the corresponding unittests.
On Thu, 26 Aug 2010 23:07:13 +0200 (CEST)
brett.cannon <python-checkins(a)python.org> wrote:
> Author: brett.cannon
> Date: Thu Aug 26 23:07:13 2010
> New Revision: 84329
> OSError is the exception raised when one tries to create a directory that
> already exists, not IOError.
It's probably simpler to catch all of them at once using
(and see PEP 3151 :-))
I use python for more than a year now and i bought a MacBook in July. I installed Python 2.7 using the .dmg archive on the official website. After the installation I launched the Update Shell Profile.command script, but it doesn't work with ZSH. That's why I have write a small patch to be able to use this script with ZSH shell.
He simply set the path fo zsh shell.
Sorry for errors in the e-mail and the patch, but i'm french student and it is my first patch.
Hoping that it is useful for you, best regards
To those beginners in programming that are not English speakers there
are 3 problems to be solved:
1) the logic (this is unavoidable)
2) the programming language (hard but quite simple)
3) the messages (hard and not simple)
Those who could not cope with (1) could not be programmers
(2) difficult but not the main (so a 2nd step)
(3) the worst but more treatable and more largely useful
The i18n of (2) is mainly to be used in initial stages and could not
be generally applicable (maybe just some European languages). This
probably could require to rewrote the scanner (or maybe only the
grammar, I haven't gone so deep yet) so it's not that big of a
problem, it hardly affects the parser and interpreter, that are the
more complex tasks.
If (3) could enter the main trunk it would be a great help by itself.
In this case access to international help is useless due the original
difficulties with the language, remember I'm talking about kids
mainly, and 1st stage to programming for youngsters. There are two
main ways to do this, one is using codes as indicated, but I prefer
using the more generally accepted and used, with messages catalogs
using gettext and the like.
Any way thanks for your comments.
2010/8/17 Anders Sandvig <anders.sandvig(a)gmail.com>
> On Sat, Aug 14, 2010 at 10:18 AM, Jeroen Ruigrok van der Werven
> <asmodai(a)in-nomine.org> wrote:
> > I doubt you will be able to localize much with regard to the interpreter.
> > The only thing that really comes to mind are the error and exception
> > messages, but you will never be able to localize the errors themselves. The
> > problem there is that if they seek help on international fora for Python,
> > other people might have no clue what the (error) message even means.
> I think one way to solve this might be to include the original
> (English) error message as well as the translation. I've noticed this
> is how error messages are handled in localized versions of Oracle, and
> although I'm personally annoyed by it, I can see how some people might
> find it useful.
> For example:
> >>> cause.error()
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> NameError: name 'cause' is not defined
> localized to Norwegian, could become:
> >>> cause.error()
> Tilbakesporing (nyeste kall sist):
> Fil "<stdin>", linje 1, i <module>
> NameError: navn 'cause' er ikke definert (name 'cause' is not defined)
> I think translating the actual error text would make sense, but I'm
> not so sure about localizing the traceback output itself...