I frequently use Python from the interactive interpreter as a shell. It is
a frequent, but mild, irritant that I have to type os.listdir('.') instead
of just os.listdir().
How about making '.' a default argument for os.listdir ?
All the best,
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
The last thread about "Posting style" makes me think that effective
communication with email is impossible at all in modern world, where time
pressure doesn't allow to read responses, not speaking about properly
formatting them or following guidelines. The problem with email threads
that they can be hijacked, polluted with irrelevant info (context garbage),
personal opinions etc. If the aim of the thread is to "sell" some idea, it
is almost impossible to track when people change their minds. And the
biggest problem is that *email threads are stateless*. Meaning that to get
the current state of the problem everybody needs to waste a lot of time to
reread the thread and filter it. Sometimes it just takes too much time.
So I propose to have a summary for each thread in Etherpad -
http://en.wikipedia.org/wiki/Etherpad - that will provide current current
summary of email thread, describing original problem, its evolution,
arguments and counter-arguments.
I propose two new control flows for Python:
"while ... try":
while expr try:
This executes suite1 as long as handled exceptions are thrown and expr
* If an unhandled exception is thrown, it passes the exception on to the
surrounding or the stack.
* If no exception occurs, life goes on as normal, suite3 is executed and
execution goes on afterwards.
The control flow is thus equivalent to:
But it's neater, very natural (in my opinion) and saves an indentation
One further enhancement: If expr is encountered to be False, some
special exception "NoMoreTriesException" could be raised. It can be
catched in the same "while ... try" block.
while network_is_up() try:
print("Couldn't establish connection")
while receive_packet() try:
print("You sent the wrong thing. Try again.")
print("I couldn't get a single useful packet from you :(")
A similar thing could be made with "for ... try":
for password in passwords_i_remember try:
pass # No pun intended
print("Not a single one worked.")
The advantages are the same as for "while ... try".
I very much hope I do not embarrass the audience but people can we
return back to email etiquette? Inline quoting instead of top-posting,
proper trimming instead of overquoting, an empty line to separate quoted
text from the reply.
Sorry for the noise but can I ask at least? Yes, I am an old fart
joined the Net at 1991, but I find netiquette really useful for effective
communication and deviations from it inconvenient and annoying.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing in e-mail?
Oleg Broytman http://phdru.name/ phd(a)phdru.name
Programmers don't die, they just GOSUB without RETURN.
In Python 2 "print 'something', statement calls were unbuffered and
immediately appeared on screen.
In Python 3 "print('something', end='')" calls are buffered. This breaks
progress bars and other stuff.
1. What is more "Pythonic" and why?
2. Should Python 3 be fixed ASAP?
Just an off-the-wall thought.
Is there any reason a file object's boolean value shouldn't be false
once it's been closed? This would allow replacing "if f and f.closed:" (to
make sure you have a file and it's open) with just "if f:". Is there
some use case where you want to verify that an object is a file
object instead of None (or another false value), and don't care if
My own thought is that this is a case where status quo wins, but
thought someone else might think the idea has more merit.
Mike Meyer <mwm(a)mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Casefolding (Unicode Standard 3.13) is a more aggressive version of lowercasing.
It's purpose to assist in the implementation of caseless mapping. For example,
under lowercase "ß" -> "ß" but under casefolding "ß" -> "ss". I propose we add a
casefold() method. So, case-insensitive matching should really be
"one.casefold() == two.casefold()"
rather than "one.lower() == two.lower()".
since I moved from Java development to Python development, I really miss
the sampling profiler of jvisualvm (http://visualvm.java.net/). Perhaps
it is only me but especially for long running GUI applications, I would
really like to know why it sometimes slows down to a crawl.
cProfile is not really useful for this as it makes the software
unresponsive alone. Also if using multiple threads (like doing some I/O
in background, when using http://www.lag.net/paramiko/) it will give
I looked for an existing profiler and found statprof, mentioned in this
However, this still fails profiling multiple threads. I don't think one
can do any better without touching the interpreter core. So that's what
My approach implements the profiler from the following parts:
1. Sample Trigger: A timer that triggers taking samples of all
threads at fixed intervals.
2. Sampling function injection: Ensures that a sampling function is
called on each thread at the first opportunity after the sample
3. Sampling function: A function that assigns the current time slice
to the executing code on the thread it is called on.
Only the second part has to be implemented in the Python interpreter
core, the sample trigger and sampling functions can be provided by
external modules. My implementation of (2) can be found at
I also prepared a first implementation of (1) and (3) at
https://bitbucket.org/bluehorn/profiler_util. Using that library, I can
profile pybench with a 3 % slowdown (taking 100 profiling samples per
$ export PYTHON_PATH=$HOME/python-work/profiler_util
$ python3 -m sampling_profiler -- Tools/pybench/pybench.py -c
stock.pybench -f prof.pybench
Totals: 3119ms 3072ms +1.5% 3198ms
This also shows that the string benchmark takes the most time:
Thread MainThread (3842 samples, 38.434401 seconds)
cpu_time (cum) ticks (cum) samples (cum)
0.548 0.548 55 55 55 55
0.448 0.448 45 45 45 45
0.428 0.428 43 43 43 43
0.380 0.380 38 38 38 38
0.324 0.324 34 34 34 34
The output is explained as follows:
cpu_time: cpu time in seconds accounted to that line.
(cum): This is the cpu time including the cumulative time of the
functions called on that line. Gathering that data means that the
sampling function has to walk the stack for each sample, which will
cause a dramatic slowdown for deeply recursive calls. There should be a
switch to disable this.
ticks: Number of sampling profiler ticks accounted to that line. For my
example (where sample ticks are equidistant in wall time) this is a
measure of the time spent in that line, including any blocking calls
(cum): ... including called functions
samples: Number of times the sampling profiler function was called for
that line. This should equal ticks unless execution of that line took
longer than a profiler tick.
The remaining output should be obvious.
I have to admit that this is far from finished, but I hope to get some
feedback and perhaps even help by posting it here.
What do you think?
As you may know, the python-ideas list is opened only to subscribers. This
is inconvenient, because:
1. it requires three step subscription process
2. it is impossible to post a reply to existing thread/idea
There is a web-interface in Google Groups at
https://groups.google.com/forum/#!forum/python-ideas that can solve
problems above and provide some more nifty features such as embedded
search. But there comes another problem that messages posted through the
group doesn't end in list, because list requires subscription. I've
already tried to find a solution, but run out of time, so I summarized the
proposal at http://wiki.python.org/moin/MailmanWithGoogleGroups
I may or may not be able to publish outcomes of my research, so it would be
nice to get some help in investigating the problem and publishing a
solution on aforementioned wiki page. Thanks.
(I've added back python-ideas, because I think that is still the
>.... A new
> suite type - the ``transaction`` will be added to the language. The
> suite will have the semantics discussed above: modifying an object in
> the suite will trigger creation of a thread-local shallow copy to be
> used in the Transaction. Further modifications of the original will
> cause all existing copies to be discarded and the transaction to be
> restarted. ...
How will you know that an object has been modified?
The only ways I can think of are
(1) Timestamp every object -- or at least every mutable object -- and
hope that everybody agrees on which modifications should count.
(2) Make two copies of every object you're using in the suite; at the
end, compare one of them to both the original and the one you were
operating on. With this solution, you can decide for youself what
counts as a modification, but it still isn't straightforward; I would
consider changing a value to be changing a dict, even though
nothing in the item (header) itself changed.