date:20140828

Skip Montanaro s...@pobox.com:

 The simple hg commands are generally not all that different (in my
 limited experience) than the simple git commands, for some
 definition of simple. Stuff like clone, init, push, pull, commit,
 the small number of commands you use day in, day out. When you get
 beyond that simple core, both are confusing to me.

I don't think a working VC system needs to contain much more than that.
Hg stays closer to the simple ideal than git, which really fails at
being a black box. I don't see why git has staging or branches, for
example. Or why can't I revert my changes to a file easily?

The main problem with hg (and git) is the way cherrypicking is done.

See these graphics:

 [1]   Product-Ver1
|
| bugfix
|
V  feature development
   Product-Ver1' -- Product-Ver2'

   feature development
 [2]   Product-Ver1 --- Product-Ver2
  |
  | bugfix
  |
   cherry-picking V
   Product-Ver1' -- Product-Ver2'


My beef is this: The starting point and end result of [1] and [2] is
identical. The version histories of Product-Ver1' and Product-Ver2'
should usually also be identical. In hg and git, they are not. In CVS,
they are not. In SVN, they are not.

In TeamWare (and bitkeeper?), the version histories are identical.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

2014-08-28 Thread MRAB


On 2014-08-27 23:59, Peter Otten wrote:

Tim Chase wrote:


On 2014-08-27 23:42, MRAB wrote:

How many parameters are there? len(self.param)

Make that many placeholders and then join them together with
commas:

', '.join(['?'] * len(self.param))


I prefer the clarity of Peter Otten's suggestion of

', '.join('?' * len(self.param))

over the mild obscurity of putting it in a list before
multiplying.


As long as the OP doesn't try to transfer this to other paramstyles:


 , .join([%s]*3)
 '%s, %s, %s'
 , .join(%s*3) # OOPS
 '%, s, %, s, %, s'

I chose the list form for just this reason, because the OP said he was
very new to Python.
--
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

peter peter.mos...@talk21.com:

 Obviously this isn't going to change, but for concatenating short
 strings a and b is there any practical reason to avoid a+b?

Often, no. The biggest penalty is visual. For example, I would prefer
this:

{}/{}.format(prefix, suffix)

over

prefix + / + suffix


Really, I would and do.


Marko

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

2014-08-28 Thread peter

I used to struggle with the concept of ''.join(('hello ','world')) - it seemed 
so convoluted compared with the intuitive 'hello '+'world', and I could never 
remember the syntax.  Also, for the strings I was generally using the 
performance penalty was infinitesimal, so I was just adding complexity for the 
sake of the abstract concept of a more 'pythonic' style.

Obviously this isn't going to change, but for concatenating short strings a and 
b is there any practical reason to avoid a+b?

Peter

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat


On 28/08/2014 09:30, peter wrote:

I used to struggle with the concept of ''.join(('hello ','world')) - it seemed 
so convoluted compared with the intuitive 'hello '+'world', and I could never 
remember the syntax.  Also, for the strings I was generally using the 
performance penalty was infinitesimal, so I was just adding complexity for the 
sake of the abstract concept of a more 'pythonic' style.

Obviously this isn't going to change, but for concatenating short strings a and 
b is there any practical reason to avoid a+b?

Peter



Please quote context, there's some smart people on this list but none of 
them are mind readers :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

Hi Chris,

thanks for the reply,

On Wed, Aug 27, 2014 at 12:26:48PM -0700, Chris Kaynor wrote:
 On Wed, Aug 27, 2014 at 11:55 AM, Ervin Hegedüs airw...@gmail.com wrote:
 
  what's the correct way to terminate a thread by itself?
 
 
 To terminate the thread, the run function must exit. This can be either
 from an exception or a return statement.

you mean:

def run(self):
do_domething()
return True

is enough?

  I mean:
 
  class MyThread(threading.Thread):
  def __init__(self, queueitem):
  threading.Thread.__init__(self)
  ...
 
  def run(self):
  pseudo code below
 
  try:
 self.connect_to_database()
  except:
 
 
 First off, especially if you are going to raise an exception anyways, I
 would recommend not silencing the orignal error - it will make debugging
 harder. 

That's right - I just copied the relevant code.

 This is especially true with a bare except: statement - at least
 capture only some exceptions. Using a logger to handle the exception or use
 your except, log the error, than reraise with a bare raise statement
 would generally be preferable.
 
self.terminate(Error when connect to db)

thanks for the idea,

 
  try:
 self.create_db_table()
  except:
 self.terminate(Error when create table)
 
 
 You probably want to make sure to disconnect from the database in here.
 Possibly via a with statement or a try...finally over the entire block,
 depending on your database API.

right,
 
  in main():
 
  for q in range(0, 10):
  mt = MyThread()
  try:
  mt.run()
 
 
 This is not actually starting a thread, but is running it in-line, just
 like a normal function. You probably want mt.start() instead, which will
 cause mt.run to execute in another thread.
yes, I know that, and I've used mt.start() before the mt.run() -
I just missed out to paste that part of code - sorry.
 
 If you use mt.start() to actually start a thread, the only time it will
 fail is if the thread fails to start (such as too many running threads, or
 other out-of-resource errors). The exceptions raised inside the thread will
 not propagate outside the start call, and thus the mt.join() call inside
 the except statement will have no effect - no thread is running.

yes, I thought that, this triggered my question :)
 
  but it doesn't works - the exception showed on stdout only, and
  the thread stops of course, but I would like to handle the
  exceptions. If I call the join() inside from thread object, then
  an exception raised, cause the thread object of Threading module
  doesn't allows that...
 
 
 Not being able to call join from the thread you are joining with is
 probably a good thing - doing so would result in a dead lock: the thread is
 waiting for the thread to exit.

ah, well, I understand it now...
 
 In your case, you may want to just handle the exceptions inside the
 thread's run() function directly. If that is not possible and you really
 need to handle them inside the main thread, you would need to store off the
 error data in a variable (either passed into the thread as the args or
 kwargs arguments to the MyThread() call, or global or class variables)
 then use mt.join() to wait for the thread(s) to exit.

no, I don't need to handle it outside of thread - the point is
when the exception raised in a running thread, then the exception
be logged (that's no problem), and thread be stopped state, so
the caller function is able to call the join() that thread.
 
 In the case of handling the problems in the main thread, your main thread
 code would look something like:
 
 # Start all of the threads up-front.
 
 threads = []
 for q in range(0, 10):
 mt = MyThread()
 mt.start() # NOT mt.run() - that does not do any threading!
 threads.append(mt)
 
 # Now wait for them to complete.
 
 for thread in threads:
 thread.join()
 # Check for the status of thread here. Possibly on the thread object,
 which can be mutated in MyThread.run by assigning to members of self.
 

yes, the pseudo structure of my code is same as your here. But
the now the problem is when an exception raised, that showed at
stdout too, not just the log.

The process will be forked, and will runs in background when I'll
finished that, so it could be good to controll all messages.

 In the sample code you are doing, I am not even sure if I would use threads
 due to the added complexities associated with them. In the case of merely
 connecting to a database and creating a few tables, you can probably get by
 with doing them in a single thread: open a single connection, creating the
 tables as a sequence of operations, commit operations, and close connection.

at this time there is only one thread, as you wrote. I just try
to prepare it to higher load, when one thread will not enough...
 
 If you do in fact need threads, you may also be better off using a thread
 pool (see concurrent.futures,

Re: python string, best way to concat

On Thu, Aug 28, 2014 at 6:43 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 28/08/2014 09:30, peter wrote:

 I used to struggle with the concept of ''.join(('hello ','world')) - it
 seemed so convoluted compared with the intuitive 'hello '+'world', and I
 could never remember the syntax.  Also, for the strings I was generally
 using the performance penalty was infinitesimal, so I was just adding
 complexity for the sake of the abstract concept of a more 'pythonic' style.

 Obviously this isn't going to change, but for concatenating short strings
 a and b is there any practical reason to avoid a+b?

 Peter


 Please quote context, there's some smart people on this list but none of
 them are mind readers :)

Speak for yourself! I play a mind reader on Threshold RPG (in fact,
one of the highest level psions on the game), and several of my
brothers tell me I can pull the same tricks in real life. Or maybe I'm
just really good at knowing what problems they're having, even before
they recognize the problems themselves...

But Peter, no - no reason to avoid it for concatenating two strings.
The advantages of join() are visible when you have huge numbers of
strings; plus it's more readable than repeating a separator lots of
times, especially if you're working with variable numbers of list
elements:

https://github.com/Rosuav/runningtime/blob/master/runningtime.py#L211

The debug info is collected in a list (appending each item, and quite
a few of them are elided if they're some kind of default), and then
they're joined with ', ' as the separator. I could use string
appending for that, but there's no point; it's more readable this way.
Performance doesn't matter at all here, just readability.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

Ervin Hegedüs airw...@gmail.com:

 at this time there is only one thread, as you wrote. I just try
 to prepare it to higher load, when one thread will not enough...

Threads are a necessary evil when dealing with blocking function calls,
but evil they remain. I would generally *not* associate a thread for
each parallel context but work with a limited thread pool, whose size is
independent of the number of contexts. Often, a good rule of thumb is to
have two threads per CPU core to get most out of the hardware.

Since you talked about forking, you might be better served with a pool
of processes instead of threads since processes have less surprising
semantics and, if push came to shove, you can kill them with a signal.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program

when i run python setup.py py2exe i get this error

no module name py2exe any help please


On Wednesday, August 27, 2014 8:39:28 AM UTC-7, Grant Edwards wrote:
 On 2014-08-27, ngangsia akumbo ngang...@gmail.com wrote:
 
 
 
  i have written a small scripts in python that inputs two values and
 
  prints out the sum.
 
 
 
  Ok i want to be able to install this program on a windows 8 machine
 
  and run it as a normal program.
 
 
 
 I use py2exe for that. When I want to bundle it up with an installer,
 
 I use Inno Setup.
 
 
 
 http://www.py2exe.org/
 
 http://www.jrsoftware.org/isinfo.php
 
 
 
 It will sometimes requires some fiddling around, experimentation,
 
 burning of incense, and sacrificing of chickens [but no more than most
 
 things on Windows.]
 
 
 
 But they've always worked well for me.
 
 
 
 -- 
 
 Grant Edwards   grant.b.edwardsYow! Hey, waiter!  I want
 
   at   a NEW SHIRT and a PONY TAIL
 
   gmail.comwith lemon sauce!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

Hi Marko,

On Thu, Aug 28, 2014 at 12:02:29PM +0300, Marko Rauhamaa wrote:
 Ervin Hegedüs airw...@gmail.com:
 
  at this time there is only one thread, as you wrote. I just try
  to prepare it to higher load, when one thread will not enough...
 
 Threads are a necessary evil when dealing with blocking function calls,
 but evil they remain. I would generally *not* associate a thread for
 each parallel context but work with a limited thread pool, whose size is
 independent of the number of contexts. Often, a good rule of thumb is to
 have two threads per CPU core to get most out of the hardware.

thanks - I didn't plan to increase of size of thread pool to
greather than 2-4 - the server has 4 CPU.

 Since you talked about forking, you might be better served with a pool
 of processes instead of threads since processes have less surprising
 semantics and, if push came to shove, you can kill them with a signal.

life with threads are better in my case - the shared memory is a
big advantage. That's the only reason... :)


Thanks,


a.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program

On Thu, Aug 28, 2014 at 7:10 PM, ngangsia akumbo ngang...@gmail.com wrote:
 when i run python setup.py py2exe i get this error

 no module name py2exe any help please

Any help? Sure. I'll offer three suggestions.

1) Don't top-post.
2) Don't use Google Groups, or edit your posts before sending.
3) Use a web search to find basic information about installing py2exe,
same as I advised you before.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program

i have done so before posting here
-- 
https://mail.python.org/mailman/listinfo/python-list

Py_SetProgramName() and prefixes

2014-08-28 Thread Marko Havu

Hi,

I have a problem with Py_Initialize() not being able to find python in the 
path. Unless I use Py_SetProgramName() with the full path of the python 
interpreter, I get the following error message:
Could not find platform independent libraries prefix
Could not find platform dependent libraries exec_prefix
Consider setting $PYTHONHOME to prefix[:exec_prefix]
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named ’encodings’

Is there a way of getting this to work without setting $PYTHONHOME? I am sure 
this worked for me before. The odd part is, I haven’t touched my python 
installation or environment variables. While doing some testing, I stumbled 
across some weird behavior on Python 3.3 and 3.4: Py_GetPrefix(), Py_GetPath() 
and other functions that return paths that are supposed to be set by 
Py_SetProgramName() all return just ”/”:

 main.c 
#include Python.h
#include stdio.h
#include stdlib.h

int main(int argc, const char * argv[])
{
   printf(path: %s\n, getenv(PATH));
   Py_SetProgramName(L/anaconda/envs/python3.4/bin/python);
   Py_Initialize();
   wprintf(Lprefix: %s\n, Py_GetPrefix());
   PyRun_InteractiveLoop(stdin, stdin);
   Py_Finalize();

   return EXIT_SUCCESS;
}


Python 3.4 output (same with 3.3):

path: /anaconda/envs/python3.4/bin:/usr/bin:/bin:/usr/sbin:/sbin
prefix: /
 import sys
 sys.prefix
'/anaconda/envs/python3.4'


Python 2.7 output (setting correct path and changing char strings to wchar_t 
strings):

path: /anaconda/envs/python2.7/bin:/usr/bin:/bin:/usr/sbin:/sbin
prefix: /anaconda/envs/python2.7
 import sys
 sys.prefix
'/anaconda/envs/python2.7’

Am I doing something wrong, or is this a bug in Python 3?

Kind regards,
 Marko Havu
-- 
https://mail.python.org/mailman/listinfo/python-list

To modify IDLE source code

2014-08-28 Thread Abhiram R

Hi,
I've got the IDLE source code from IDLElib online. Now I want to modify it
so as to improve upon it i.e I have a feature in mind I want to add into
it. Is there any documentation that will help me make sense (more easily)
of each of the py files in said library?


Thanks
Abhiram
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyPI password rules

On Wed, Aug 27, 2014 at 11:28 PM, Skip Montanaro s...@pobox.com wrote:

 Hmmm... I realize now that I'm not seeing all messages, at least I don't
 think so. So much to learn about IMAP...


I peeked at the code for the SpamBayes IMAP filter. Holy smokes! I think
the IMAP RFC authors might have been sadists... Getting the IMAP access
code right is going to be the most challenging part of the rest of this
little project.

S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Py_SetProgramName() and prefixes

2014-08-28 Thread Marko Havu

I wrote earlier:

 While doing some testing, I stumbled across some weird behavior on Python 3.3 
 and 3.4: Py_GetPrefix(), Py_GetPath() and other functions that return paths 
 that are supposed to be set by Py_SetProgramName() all return just ”/”:
 
  main.c 
 #include Python.h
 #include stdio.h
 #include stdlib.h
 
 int main(int argc, const char * argv[])
 {
  printf(path: %s\n, getenv(PATH));
  Py_SetProgramName(L/anaconda/envs/python3.4/bin/python);
  Py_Initialize();
  wprintf(Lprefix: %s\n, Py_GetPrefix());
  PyRun_InteractiveLoop(stdin, stdin);
  Py_Finalize();
 
  return EXIT_SUCCESS;
 }
 

Doh. It’s supposed to be %S, not %s. When I fix that, the prefix is as 
expected, but I still have the original problem of Py_Initialize() not being 
able to find python in the path.

- Marko

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

2014-08-28 Thread Roy Smith

In article 63bdccb4-9e34-4e40-b07d-14342e218...@googlegroups.com,
 peter peter.mos...@talk21.com wrote:

 I used to struggle with the concept of ''.join(('hello ','world')) - it 
 seemed so convoluted compared with the intuitive 'hello '+'world', and I 
 could never remember the syntax.  Also, for the strings I was generally using 
 the performance penalty was infinitesimal, so I was just adding complexity 
 for the sake of the abstract concept of a more 'pythonic' style.
 
 Obviously this isn't going to change, but for concatenating short strings a 
 and b is there any practical reason to avoid a+b?

For places where performance doesn't matter, string addition is just 
fine.  The computer works for you.  If you're working for the computer, 
you're doing something wrong.

That being said, join is typically used where you have a variable number 
of strings in some iterable (e.g. a list of strings).  For exactly two 
strings, I would have probably written this as:

'%s %s' % (string1, string2)

and if I really wanted to use the join syntax, I would have moved the 
delimiter (in this case, a space), into the first string:

' '.join([string1, string2])

Be aware of the various ways, then pick the one that works for you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

2014-08-28 Thread Mihamina Rakotomandimby


On 08/28/2014 03:08 PM, Roy Smith wrote:

For places where performance doesn't matter, string addition is just
fine.  The computer works for you.  If you're working for the computer,
you're doing something wrong.


I like this :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Py_SetProgramName() and prefixes

2014-08-28 Thread Marko Havu

Marko Havu marko.h...@jyu.fi kirjoitti 28.8.2014 kello 12.58:

 I have a problem with Py_Initialize() not being able to find python in the 
 path. Unless I use Py_SetProgramName() with the full path of the python 
 interpreter, I get the following error message:
 Could not find platform independent libraries prefix
 Could not find platform dependent libraries exec_prefix
 Consider setting $PYTHONHOME to prefix[:exec_prefix]
 Fatal Python error: Py_Initialize: unable to load the file system codec
 ImportError: No module named ’encodings’

Turns out this was an Anaconda-specific problem: Py_SetProgramName() resolves 
the prefix to /opt/anaconda1anaconda2anaconda3. I sent a post to Anaconda 
public support forum (anaco...@continuum.io) to find out whether it can be 
solved without setting $PYTHONHOME or calling Py_SetProgramName() with a full 
path.

Thanks for your kind help,
 Marko Havu

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program


thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Py_SetProgramName() and prefixes

On Thu, Aug 28, 2014 at 10:42 PM, Marko Havu marko.h...@jyu.fi wrote:
 Thanks for your kind help,

Glad you got what you needed! I read your original post and had no
idea what the issue was, so I skipped passed it and dealt with other
posts instead. But sometimes the mere act of posting the question
gives you what you need... and maybe this was one of them.

All the best!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is acceptable as 'open-source'? [was Python vs C++]

2014-08-28 Thread Frank Millman


Chris Angelico ros...@gmail.com wrote in message 
news:captjjmp_jfxth_l6us30gbotmbyhw_imu-pjdglevgj2nut...@mail.gmail.com...
 On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman fr...@chagford.com wrote:

 This is quite a timely message for me. I am inching closer to releasing a
 version of my accounting software, and a lot of the above comments apply 
 to
 me as well. At present I am the only developer, and my project is not 
 hosted
 anywhere, so I have to decide how to make it available, and I am open to
 suggestions.


[...]


 Go public first, and watch what people get confused at - then document
 those parts. If you try to document everything first, you'll spend
 heaps of time and effort on it, and maybe won't even be happy with the
 result.


I *think* I have created a project on GitHub and uploaded my software there. 
It is called AccInABox.

This name probably needs a bit of explanation. Acc is an accountant. Box 
is the computer. You can set the system up with various rules and 
parameters, and then leave your staff to operate it without supervision. The 
program acts as your accountant, and will control what the staff can and 
cannot do.

At the last count, there are about 10 million things I still have to do 
before it is a working product. But the structure feels quite stable now, 
and you can do a few simple things with it, so I am ready for people to have 
a look and offer feedback.

I don't know GitHub at all, and I don't know what other information you 
need, so please let me know whether it works.

Frank



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

On Wed, Aug 27, 2014 at 1:55 PM, Ervin Hegedüs airw...@gmail.com wrote:

 what's the correct way to terminate a thread by itself?


If this is something you need to do as a regular course of business, I'd
share a Queue between the main thread and the target thread. When you want
it to exit, shoot it a command to do so over the queue. If it's a worker
thread of some sort, set it as a daemon thread. When your main thread exits
and there are no other non-daemon threads alive, the program will exit.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What is acceptable as 'open-source'? [was Python vs C++]

On Thu, Aug 28, 2014 at 11:44 PM, Frank Millman fr...@chagford.com wrote:
 I *think* I have created a project on GitHub and uploaded my software there.
 It is called AccInABox.

https://github.com/FrankMillman/AccInABox

Seems to be all there!

You seem to have a default README.md as well as your README that has
real content in it. If you delete README.md, the other one should
become visible on the main project page. I'll shoot through a PR for
that.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyPI password rules

2014-08-28 Thread Ethan Furman


On 08/27/2014 08:32 PM, Chris Angelico wrote:


I'm not sure I understand how your 'common' value works, though. Does
the default 0.6 mean you take the 60% most common words? Those above
the 60th percentile of frequency? Something else?


What's the value in ruling out less common words?  I would think the more the 
merrier!

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: PyPI password rules

On Fri, Aug 29, 2014 at 12:21 AM, Ethan Furman et...@stoneleaf.us wrote:
 On 08/27/2014 08:32 PM, Chris Angelico wrote:


 I'm not sure I understand how your 'common' value works, though. Does
 the default 0.6 mean you take the 60% most common words? Those above
 the 60th percentile of frequency? Something else?


 What's the value in ruling out less common words?  I would think the more
 the merrier!

Memorability. It's optional, but it can help if you're not getting
arbitrary words from sci/med jargon.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyPI password rules

On Thu, Aug 28, 2014 at 9:21 AM, Ethan Furman et...@stoneleaf.us wrote:

 What's the value in ruling out less common words?  I would think the more
 the merrier!


I think less common words are likely to actually not be words, just
misspellings of other words, and thus harder for the user to remember. More
cruft to ignore/eliminate. The sources for the corpus being (in my case)
public mailing lists or (in Chris's case) DD chatter, the likelihood of
misspellings is pretty high.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python string, best way to concat

On 28/08/2014 13:08, Roy Smith wrote:

In article 63bdccb4-9e34-4e40-b07d-14342e218...@googlegroups.com,
peter peter.mos...@talk21.com wrote:

I used to struggle with the concept of ''.join(('hello ','world')) - it
seemed so convoluted compared with the intuitive 'hello '+'world', and I
could never remember the syntax. Also, for the strings I was generally using
the performance penalty was infinitesimal, so I was just adding complexity
for the sake of the abstract concept of a more 'pythonic' style.

Obviously this isn't going to change, but for concatenating short strings a
and b is there any practical reason to avoid a+b?

For places where performance doesn't matter, string addition is just
fine. The computer works for you. If you're working for the computer,
you're doing something wrong.

That being said, join is typically used where you have a variable number
of strings in some iterable (e.g. a list of strings). For exactly two
strings, I would have probably written this as:

'%s %s' % (string1, string2)

and if I really wanted to use the join syntax, I would have moved the
delimiter (in this case, a space), into the first string:

' '.join([string1, string2])

Be aware of the various ways, then pick the one that works for you.

Which reminds me of
http://code.activestate.com/recipes/577845-format_iter-easy-formatting-of-arbitrary-iterables/

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program


On 28/08/2014 10:31, ngangsia akumbo wrote:

i have done so before posting here



Done what, fed the cat?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Tim Chase

On 2014-08-28 08:58, Marko Rauhamaa wrote:
 The main problem with hg (and git) is the way cherrypicking is done.
 
 See these graphics:
 
  [1]   Product-Ver1
 |
 | bugfix
 |
 V  feature development
Product-Ver1' -- Product-Ver2'
 
feature development
  [2]   Product-Ver1 --- Product-Ver2
   |
   | bugfix
   |
cherry-picking V
Product-Ver1' -- Product-Ver2'
 
 
 My beef is this: The starting point and end result of [1] and [2] is
 identical. The version histories of Product-Ver1' and Product-Ver2'
 should usually also be identical. In hg and git, they are not. In
 CVS, they are not. In SVN, they are not.
 
 In TeamWare (and bitkeeper?), the version histories are identical.

I'm not sure how you arrive at the conclusion that git/hg/cvs/svn
are wrong and TeamWare et al. are correct.  If you diff the two,
you'll find that the end result is the same, but the history is
different.  At least git/hg/bzr ensure that the historical tree that
I have and the historical tree that you have are identical.  In your
description, their histories are not.  This ensures that when I speak
about the ancestor of Product-Ver2, we're both talking about the
same thing.  In #1, that's Product-Ver1' while in #2, that's
Product-Ver2.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To modify IDLE source code


On 28/08/2014 11:34, Abhiram R wrote:

Hi,
I've got the IDLE source code from IDLElib online. Now I want to modify
it so as to improve upon it i.e I have a feature in mind I want to add
into it. Is there any documentation that will help me make sense (more
easily) of each of the py files in said library?

Thanks
Abhiram



Not that I'm aware of.  I suggest you check out the bug tracker at 
bugs.python.org as there are a lot of issues against IDLE there.  See 
also IDLEX at https://pypi.python.org/pypi/idlexa and the IDLE mailing 
list at either https://mail.python.org/mailman/listinfo/idle-dev or 
gmane.comp.python.idle


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Ned Batchelder


On 8/28/14 1:58 AM, Marko Rauhamaa wrote:


The main problem with hg (and git) is the way cherrypicking is done.

See these graphics:

  [1]   Product-Ver1
 |
 | bugfix
 |
 V  feature development
Product-Ver1' -- Product-Ver2'

feature development
  [2]   Product-Ver1 --- Product-Ver2
   |
   | bugfix
   |
cherry-picking V
Product-Ver1' -- Product-Ver2'


My beef is this: The starting point and end result of [1] and [2] is
identical. The version histories of Product-Ver1' and Product-Ver2'
should usually also be identical. In hg and git, they are not. In CVS,
they are not. In SVN, they are not.

In TeamWare (and bitkeeper?), the version histories are identical.



I feel like I am misunderstanding you.  My summary of what you just said 
is, I have two scenarios where my code went through different sequences 
of changes to end up with the same content.  I expect both of those 
paths will show the same history.  That sounds nonsensical to me, so I 
must be misunderstanding you.  The path the file followed (that is, the 
sequence of changes that made the file what it is), *is* the history of 
the file.  If two different sequences of changes can result in the same 
history, then one (or both!) of the histories are wrong in that they 
don't accurately reflect the sequence of changes that happened.


Maybe you can elaborate?

--
Ned Batchelder, http://nedbatchelder.com

--
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program

thanks i figured it out
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: running a python program


On 28/08/2014 16:53, ngangsia akumbo wrote:

thanks i figured it out



So what did you feed the cat in the end?  Or are we on a new topic?  Or 
what?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

Ned Batchelder n...@nedbatchelder.com:

 I feel like I am misunderstanding you.  My summary of what you just said
 is, I have two scenarios where my code went through different sequences
 of changes to end up with the same content.  I expect both of those
 paths will show the same history.  That sounds nonsensical to me, so I
 must be misunderstanding you.  The path the file followed (that is, the
 sequence of changes that made the file what it is), *is* the history of
 the file.

Not the file but the repository.

Imagine we have CPython 3.9. It might have an ancient implementation of
the deque. Then somebody realizes there's an embarrassing bug that
requires a simple fix in a C file. The fix is implemented in HEAD. Then,
it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use
hg pull for the propagation since hg would insist on propagating all
the unrelated features as well.

With TeamWare, Bitkeeper(?) and CVS the process is simple since they
retain the file scope. Propagating a fix from HEAD to 3.0 is equivalent
to propagating a fix from 3.0 to HEAD. After the pull/push, if you look
at the version history, you couldn't say which way the process went
since the pull/push operation itself doesn't leave a trace. (Well, in
CVS, it does, but that's bad.)

In large repositories (like CPython), you have independent modules with
relatively independent (and typically linear) histories. Hg and git
don't want to respect that independence.

As I said before, the problem is alleviated or goes away if you split
your large repositories into tiny repositories. Then, looking at the
example above, you could have a collections repository. CPython 3.0 and
3.9 might use the same version of the collections component. The bug
would then be fixed in collections and both CPython 3.0 and 3.9 would
simply update their component dependency to the latest and greatest
collections.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

2014-08-28 Thread Chris Kaynor

On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs airw...@gmail.com wrote:

   In your case, you may want to just handle the exceptions inside the
  thread's run() function directly. If that is not possible and you really
  need to handle them inside the main thread, you would need to store off
 the
  error data in a variable (either passed into the thread as the args or
  kwargs arguments to the MyThread() call, or global or class variables)
  then use mt.join() to wait for the thread(s) to exit.

 no, I don't need to handle it outside of thread - the point is
 when the exception raised in a running thread, then the exception
 be logged (that's no problem), and thread be stopped state, so
 the caller function is able to call the join() that thread.


In this case, all that needs to happen is for the thread's run function to
either throw an exception (as happens in the error case in your sample
code) or return.

The threading module will cause it to print any exception that occurs by
default.


   In the case of handling the problems in the main thread, your main
 thread
  code would look something like:
 
  # Start all of the threads up-front.
 
  threads = []
  for q in range(0, 10):
  mt = MyThread()
  mt.start() # NOT mt.run() - that does not do any threading!
  threads.append(mt)
 
  # Now wait for them to complete.
 
  for thread in threads:
  thread.join()
  # Check for the status of thread here. Possibly on the thread object,
  which can be mutated in MyThread.run by assigning to members of self.
 

 yes, the pseudo structure of my code is same as your here. But
 the now the problem is when an exception raised, that showed at
 stdout too, not just the log.


If what you want is to make sure the error is not printed to stderr, you'll
just need to make sure the thread's run function does not exit with an
exception. The simpliest way to do that would be to wrap the entire
thread's run function in a try...catch statement, like so:

class Thread(threading.Thread)

def run(self):

try:

 # Do your code here.

# You can also have more specific error-handling inside here if needed.

except Exception as err:

# Log your error here - you will be silencing it and therefore unable to
see it in the TTY!

# If you want to be able to handle the errors in the main thread, you could
run code like the following:

#self.err = err

 # Where you can check and access them on the main thread.

return # Optional if there is no other code outside the try...except.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Tim Chase

On 2014-08-28 19:17, Marko Rauhamaa wrote:
  I feel like I am misunderstanding you.  My summary of what you
  just said is, I have two scenarios where my code went through
  different sequences of changes to end up with the same content.
  I expect both of those paths will show the same history.  That
  sounds nonsensical to me, so I must be misunderstanding you.  The
  path the file followed (that is, the sequence of changes that
  made the file what it is), *is* the history of the file.  
 
 Not the file but the repository.
 
 Imagine we have CPython 3.9. It might have an ancient
 implementation of the deque. Then somebody realizes there's an
 embarrassing bug that requires a simple fix in a C file. The fix is
 implemented in HEAD. Then, it is propagated down to 3.9, 3.8, ...
 3.0. You obviously couldn't use hg pull for the propagation since
 hg would insist on propagating all the unrelated features as well.

No, you wouldn't use hg pull nor git pull but rather git
cherry-pick or what Mercurial calls transplant (I've not used this
in Mercurial, but I believe it's an extension).

That would apply just that patch/diff to the older version rather
than the entire history of changes between 3.{n9} and 3.9 versions.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 2:17 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Imagine we have CPython 3.9. It might have an ancient implementation of
 the deque. Then somebody realizes there's an embarrassing bug that
 requires a simple fix in a C file. The fix is implemented in HEAD. Then,
 it is propagated down to 3.9, 3.8, ... 3.0. You obviously couldn't use
 hg pull for the propagation since hg would insist on propagating all
 the unrelated features as well.

What you're saying, though, is that there's something inherently
special about file boundaries. You want files to be magically
separable within a repo. Why? What's the significance of the file?

In reality, it's highly unlikely that this simple fix is the only
change that's ever occurred to that file, so I very much doubt that
your proposal would even work. With git/hg, the merge is exactly the
same whether there've been changes to other files or changes to other
parts of the same file, because file boundaries just aren't that
special. This is basically a cherry-picking job; I know how to do it
in git (git cherry-pick some_commit_reference), although I'm not sure
the best way in hg - a quick Google search suggests 'hg graft', but at
very worst, all you have to do is export a patch and reimport it.
Chances are it'll apply cleanly even in cases where your proposed
magic wouldn't work.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

On Fri, Aug 29, 2014 at 2:23 AM, Chris Kaynor ckay...@zindagigames.com wrote:
 If what you want is to make sure the error is not printed to stderr, you'll
 just need to make sure the thread's run function does not exit with an
 exception. The simpliest way to do that would be to wrap the entire thread's
 run function in a try...catch statement, like so:

 class Thread(threading.Thread)
 ...
 except Exception as err:

This is actually something where it may be appropriate to catch
BaseException, since you are terminating the thread immediately
anyway. If you get a KeyboardInterrupt or something, you'll catch it,
log it, and end the thread.

Note, though, that retaining the actual error object risks resource
leakage. You glom onto all sorts of locals, via the backtrace. Unless
you're going to handle the exception and then dispose of the whole
thread object, I'd advise caution; maybe consider taking a textual
snapshot of the backtrace.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To modify IDLE source code

2014-08-28 Thread Terry Reedy


On 8/28/2014 6:34 AM, Abhiram R wrote:

Hi,
I've got the IDLE source code from IDLElib online.


It also come with Python unless a distribution removes it.


Now I want to modify it so as to improve upon it i.e

 I have a feature in mind I want to add into it.

If I may ask, what?
For yourself only, or everyone?
Have you checked the tracker for existing issues?


Is there any documentation that will help me make sense (more
easily) of each of the py files in said library?


I believe config-extensions.def has the main informtion on writing 
extensions.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Terry Reedy


On 8/28/2014 12:17 PM, Marko Rauhamaa wrote:


Imagine we have CPython 3.9. It might have an ancient implementation of
the deque. Then somebody realizes there's an embarrassing bug that
requires a simple fix in a C file. The fix is implemented in HEAD. Then,
it is propagated down to 3.9, 3.8, ... 3.0.


For CPython and mecurial, that is the wrong direction. We start with the 
earliest branch and merge forward. Security fixes start with 3.2, bug 
fixes with 3.4.



You obviously couldn't use hg pull for the propagation


One uses hg merge to merge, so this does not make sense.

 since hg would insist on propagating all

the unrelated features as well.


Once a patch has been pushed, others pull it. So one does use hg pull 
for propagation in that sense. For each branch, one gets the patches 
that have been applied to the branch, as one should. It is our intention 
that each changeset, whether applied to one or many files, leaves the 
repository in a coherent state.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

Hi Chris,

thanks for you answer,

On Thu, Aug 28, 2014 at 09:23:24AM -0700, Chris Kaynor wrote:
 On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs airw...@gmail.com wrote:
 
In your case, you may want to just handle the exceptions inside the
   thread's run() function directly. If that is not possible and you really
   need to handle them inside the main thread, you would need to store off
  the
   error data in a variable (either passed into the thread as the args or
   kwargs arguments to the MyThread() call, or global or class variables)
   then use mt.join() to wait for the thread(s) to exit.
 
  no, I don't need to handle it outside of thread - the point is
  when the exception raised in a running thread, then the exception
  be logged (that's no problem), and thread be stopped state, so
  the caller function is able to call the join() that thread.
 
 
 In this case, all that needs to happen is for the thread's run function to
 either throw an exception (as happens in the error case in your sample
 code) or return.

now the code looks like this:

  def run(self):
try:
  connect_to_db()
except:
  self._exit(-1, Connection error, sys.exc_info()[1])
  return True

try:
  do_another_thing()
except:
  self._exit(-2, Another error, sys.exc_info()[1])
  return True

so, the thread's _exit() functions set many things, logs to
exception error, but not terminate the thread. As you can see,
all except line of try block contains a return - that's what I
wanted to avoid.
 
 The threading module will cause it to print any exception that occurs by
 default.

yes, I saw that :),
 
  yes, the pseudo structure of my code is same as your here. But
  the now the problem is when an exception raised, that showed at
  stdout too, not just the log.
 
 
 If what you want is to make sure the error is not printed to stderr, you'll
 just need to make sure the thread's run function does not exit with an
 exception. The simpliest way to do that would be to wrap the entire
 thread's run function in a try...catch statement, like so:

I've re-indented your code below:

 class Thread(threading.Thread)
 
   def run(self):
 try:
   # Do your code here.
   # You can also have more specific error-handling inside here if needed.
 except Exception as err:
   # Log your error here - you will be silencing it and therefore unable to
   # see it in the TTY!

Now I don't see the key different between your code, and my
example - looks like there are same. But when I tried to throw an
exception, that showed in TTY. Nevermind, now it works, only the
necessary return keyword would be good to leave.

 # If you want to be able to handle the errors in the main thread, you could
 run code like the following:
 
 #self.err = err
 
  # Where you can check and access them on the main thread.
 
 return # Optional if there is no other code outside the try...except.

I don't see your opinion from this snippet, but I think my
solution is very similar like yours :)


Thanks for the help again,


a.

-- 
I � UTF-8
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

Chris Angelico ros...@gmail.com:

 What you're saying, though, is that there's something inherently
 special about file boundaries. You want files to be magically
 separable within a repo. Why? What's the significance of the file?

Files do have that magic property. That's only an approximation, but it
is a very accurate and fitting approximation. Developers have a strong
tendency of collecting functions to files. More to the point,
functionality may be split across multiple files, but a large repository
is far too blunt an abstraction.

As I have mentioned, Darcs tries to get everything right. I haven't used
it, but I have read it sometimes gets entangled in its smart algorithms.

 In reality, it's highly unlikely that this simple fix is the only
 change that's ever occurred to that file, so I very much doubt that
 your proposal would even work.

I have actually found the reverse to be true. Most fixes are very local,
and in large repositories, most files don't experience any change for
over numerous releases.

 With git/hg, the merge is exactly the same whether there've been
 changes to other files or changes to other parts of the same file,
 because file boundaries just aren't that special. This is basically a
 cherry-picking job;

Yes, that's cherry-picking. You also have manual patching and manual
editing. All methods are in use, manual editing in particular. That's
because of the awkward repo-level abstraction.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

2014-08-28 Thread Chris Kaynor

On Thu, Aug 28, 2014 at 11:39 AM, Ervin Hegedüs airw...@gmail.com wrote:

 Hi Chris,

 thanks for you answer,

 On Thu, Aug 28, 2014 at 09:23:24AM -0700, Chris Kaynor wrote:
  On Thu, Aug 28, 2014 at 1:52 AM, Ervin Hegedüs airw...@gmail.com
 wrote:
  
 In your case, you may want to just handle the exceptions inside the
thread's run() function directly. If that is not possible and you
 really
need to handle them inside the main thread, you would need to store
 off
   the
error data in a variable (either passed into the thread as the
 args or
kwargs arguments to the MyThread() call, or global or class
 variables)
then use mt.join() to wait for the thread(s) to exit.
  
   no, I don't need to handle it outside of thread - the point is
   when the exception raised in a running thread, then the exception
   be logged (that's no problem), and thread be stopped state, so
   the caller function is able to call the join() that thread.
 
 
  In this case, all that needs to happen is for the thread's run function
 to
  either throw an exception (as happens in the error case in your sample
  code) or return.

 now the code looks like this:

   def run(self):
 try:
   connect_to_db()
 except:
   self._exit(-1, Connection error, sys.exc_info()[1])
   return True

 try:
   do_another_thing()
 except:
   self._exit(-2, Another error, sys.exc_info()[1])
   return True


You could also do this this way:

def run(self):
try:
try:
  connect_to_db()
except:
  self._exit(-1, Connection error, sys.exc_info()[1])
  raise # could do something similar inside self._exit instead.

try:
  do_another_thing()
except:
  self._exit(-2, Another error, sys.exc_info()[1])
  raise # could do something similar inside self._exit instead.
except:
return True

I'm not sure that is any clearer.

depending on what you are doing with the first two arguments to self._exit,
the following might also work:

def run(self):
try:
connect_to_db()
do_another_thing()
except:
self._exit(*sys.exc_info())
return True

Of course, this has the issue that you do not get your extra information,
however, from my experience, typically the error type, message, and
traceback are sufficient, and rarely have I needed to provide additional
details.


 so, the thread's _exit() functions set many things, logs to
 exception error, but not terminate the thread. As you can see,
 all except line of try block contains a return - that's what I
 wanted to avoid.

  The threading module will cause it to print any exception that occurs by
  default.

 yes, I saw that :),

   yes, the pseudo structure of my code is same as your here. But
   the now the problem is when an exception raised, that showed at
   stdout too, not just the log.
  
 
  If what you want is to make sure the error is not printed to stderr,
 you'll
  just need to make sure the thread's run function does not exit with an
  exception. The simpliest way to do that would be to wrap the entire
  thread's run function in a try...catch statement, like so:

 I've re-indented your code below:

  class Thread(threading.Thread)
 
def run(self):
  try:
# Do your code here.
# You can also have more specific error-handling inside here if
 needed.
  except Exception as err:
# Log your error here - you will be silencing it and therefore
 unable to
# see it in the TTY!

 Now I don't see the key different between your code, and my
 example - looks like there are same. But when I tried to throw an
 exception, that showed in TTY. Nevermind, now it works, only the
 necessary return keyword would be good to leave.


Effectively, your formatting is the same as what I was suggesting - I was
merely adding that you could wrap the entire block inside of a single
try..except rather than having multiple ones. That does have some drawbacks
(as mentioned above).

One solution I did not mention before, but is plausible, is to
monkey-patch/override the threading module to change the behavior
of _bootstrap_inner or _bootstrap to behave differently. As these are on
the Thread class, you could override them in your subclass or a base
subclass (depending on the number of Thread subclasses you have) that
behaves differently. Perhaps by making it call sys.excepthook. At one
point, we discussed doing something similar at work as we normally print
exceptions to custom streams that provide color formatting to make the
exceptions easier to find and read (exception message printed in red,
traceback in a dark red), as well as log.

Chris
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: importlib.util.find_spec()

2014-08-28 Thread Twirlip2

Excuse me for following up my own post; also, for continuing to use Google
Groups (but I've been browsing news.gmane.org, with the intention of using
it in future - once I understand how to use it).

I should have read this:

http://legacy.python.org/dev/peps/pep-0451/
PEP 451 -- A ModuleSpec Type for the Import System
Status: Final

 *submodule_search_locations*
 
 The list of location strings, typically directory paths, in which to
 search for submodules. If the module is a package this will be set
 to a list (even an empty one). Otherwise it is None.

That explains the thing that was most puzzling me.

Here is the code I have written.  If you want to try it, you'll need to:
remove the 'self' argument; replace the methods self.prompt_print() and
self.prompt_input() with the functions print() and input() respectively;
replace the functions lines_in_file() and lines_of_code() with stubs, or
some useful functions of your own devising. (Of course, I'll post my own
code, if asked - but I don't want to make [more of?] a nuisance of myself
by posting a lot of irrelevant crap unasked!  My function lines_of_code()
doesn't work properly, anyway - for example, the script 'antigravity.py',
in the Python standard library, breaks it.)

(No doubt Google Groups will reformat this horribly:)

def process(self):
Not documented yet; but see documentation for the abstract
base class UserToken, whose process() function this overrides.
See also 'PEP 451 -- A ModuleSpec Type for the Import System'.


while True:
self.prompt_print('Type the name of a Python source code file')
self.prompt_print('(omitting the invariable \'.py\' extension): ')
name = self.prompt_input()
if not name:
return None # This is the only exit.
else:
spec = find_spec(name)
if not spec:
print('\'%s\' is not on the Python search path.' % name)
elif not spec.has_location:
print('\'%s\' is a Python built-in name.' % name)
elif not hasattr(spec, 'submodule_search_locations'):
print('BUG (?): No submodule_search_locations for \'%s.\''
% name)
else: # spec exists, and has the required attribute (a list).
submodules = spec.submodule_search_locations
if submodules is not None:
print('\'%s\' is a Python package (not built-in).'
% name)
if submodules:
   print('Submodule search location(s):')
   for s in submodules:
  print(s)
else:
print('No submodule search locations are listed.')
elif not hasattr(spec, 'origin'):
print('BUG (?): No origin string for %s.py.' % name)
else: # attribute value is None, so this is not a package.
path = spec.origin
text = lines_in_file(path)
code = lines_of_code(path)
docs = text - code
print('\n%s\nis a Python source file consisting of'
% path)
print('%u lines of plain text, of which' % text)
print('%u are executable Python code, and' % code)
print('%u are docstrings, comments, or blank lines.\n'
% docs)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

Hi Chris,

On Thu, Aug 28, 2014 at 12:34:18PM -0700, Chris Kaynor wrote:
 On Thu, Aug 28, 2014 at 11:39 AM, Ervin Hegedüs airw...@gmail.com wrote:
 
  now the code looks like this:
 
def run(self):
  try:
connect_to_db()
  except:
self._exit(-1, Connection error, sys.exc_info()[1])
return True
 
  try:
do_another_thing()
  except:
self._exit(-2, Another error, sys.exc_info()[1])
return True
 
 
 You could also do this this way:
 
 def run(self):
 try:
 try:
   connect_to_db()
 except:
   self._exit(-1, Connection error, sys.exc_info()[1])
   raise # could do something similar inside self._exit instead.
 
 try:
   do_another_thing()
 except:
   self._exit(-2, Another error, sys.exc_info()[1])
   raise # could do something similar inside self._exit instead.
 except:
 return True
 
 I'm not sure that is any clearer.

thank's, may be I'll check this way soon,
 
 depending on what you are doing with the first two arguments to self._exit,
 the following might also work:
 
 def run(self):
 try:
 connect_to_db()
 do_another_thing()
 except:
 self._exit(*sys.exc_info())
 return True

The first argument is a status, this is passed to the item, which passed
to thread - so the thread sets that status, and the main loop knows,
which item needs to pass to a thread. Eg. if the DB connection
has failed, it needs to run again, at later. But if that item is
parsed and finished (eg. table exists in db), then the item
is deletable from the queue.

 Of course, this has the issue that you do not get your extra information,
 however, from my experience, typically the error type, message, and
 traceback are sufficient, and rarely have I needed to provide additional
 details.

right, that's clear.
 
  Now I don't see the key different between your code, and my
  example - looks like there are same. But when I tried to throw an
  exception, that showed in TTY. Nevermind, now it works, only the
  necessary return keyword would be good to leave.
 
 
 Effectively, your formatting is the same as what I was suggesting - I was
 merely adding that you could wrap the entire block inside of a single
 try..except rather than having multiple ones. That does have some drawbacks
 (as mentioned above).

ok,
 
 One solution I did not mention before, but is plausible, is to
 monkey-patch/override the threading module to change the behavior
 of _bootstrap_inner or _bootstrap to behave differently. As these are on
 the Thread class, you could override them in your subclass or a base
 subclass (depending on the number of Thread subclasses you have) that
 behaves differently. Perhaps by making it call sys.excepthook. At one
 point, we discussed doing something similar at work as we normally print
 exceptions to custom streams that provide color formatting to make the
 exceptions easier to find and read (exception message printed in red,
 traceback in a dark red), as well as log.

oh, that would be a big gun - and I don't feel that knowledge to
made that with security and stability.

I think this solution will enough at first time :), I didn't used
anytime the threads (in serious project).
 

Thanks for the help,


a.


-- 
I � UTF-8
-- 
https://mail.python.org/mailman/listinfo/python-list

When does True == True

2014-08-28 Thread Seymore4Head

import math
import random
import sys
pigword=Razzamattaz
print (Pig Latin)
print (Pick a word containing only alphabetical characters,pigword)
if len(pigword)  0:
print (pigword)
else:
print (empty)
if pigword.isalpha() == True:
print (pigword)
print (True)
else:
print (WTF)
print(pigword.isalpha())

What am I doing wrong?

pigword isalpha
the test for true should have passed.
The test for true din't pass even though it prints pigword.isalpha()
True after the else statment.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: When does True == True

2014-08-28 Thread Andrew Berg

On 2014.08.28 15:38, Seymore4Head wrote:
 What am I doing wrong?
 True == True
True
 True == True
False
 type(True)
class 'bool'
 type(True)
class 'str'

Also, if is already a boolean test, and it is more Pythonic to simply write if
pigword.isalpha():.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: When does True == True

2014-08-28 Thread Joel Goldstick

On Aug 28, 2014 4:45 PM, Seymore4Head Seymore4Head@hotmail.invalid
wrote:

 import math
 import random
 import sys
 pigword=Razzamattaz
 print (Pig Latin)
 print (Pick a word containing only alphabetical characters,pigword)
 if len(pigword)  0:
 print (pigword)
 else:
 print (empty)
 if pigword.isalpha() == True:
 print (pigword)
 print (True)
 else:
 print (WTF)
 print(pigword.isalpha())

 What am I doing wrong?
True is not True

 pigword isalpha
 the test for true should have passed.
 The test for true din't pass even though it prints pigword.isalpha()
 True after the else statment.
 --
 https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: When does True == True

2014-08-28 Thread Seymore4Head

On Thu, 28 Aug 2014 15:52:48 -0500, Andrew Berg
aberg...@my.hennepintech.edu wrote:

On 2014.08.28 15:38, Seymore4Head wrote:
 What am I doing wrong?
 True == True
True
 True == True
False
 type(True)
class 'bool'
 type(True)
class 'str'

Also, if is already a boolean test, and it is more Pythonic to simply write if
pigword.isalpha():.

I get it.
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

xml issue with Type 'bool' cannot be serialized

2014-08-28 Thread Noah


Hi list,

I am not clear how to fix this issue.

Traceback (most recent call last):
  File ./command.py, line 81, in module
connect(host, USER, PASSWORD)
  File ./command.py, line 63, in connect
dump = etree.tostring(xml_cmd)
  File lxml.etree.pyx, line 3165, in lxml.etree.tostring 
(src/lxml/lxml.etree.c:69414)

TypeError: Type 'bool' cannot be serialized.


here is snippets from the code



--- code ---

from jnpr.junos import Device
from jnpr.junos.utils.config import Config
from lxml import etree
import jnpr.junos.exception
import sys, os, time, re, getopt

def connect(host, user, password):
conn = Device(host=host, user=user, password=password).open()

xml_cmd = ''
xml_cmd = conn.rpc.get_configuration()
dump = etree.tostring(xml_cmd)
print dump

--
https://mail.python.org/mailman/listinfo/python-list

Draft PEP - get the regex module into stdlib


Here it is in full, comments welcome.

Please refer to http://bugs.python.org/issue2636

That's all folks.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Tim Delaney

On 29 August 2014 02:32, Tim Chase python.l...@tim.thechases.com wrote:


 No, you wouldn't use hg pull nor git pull but rather git
 cherry-pick or what Mercurial calls transplant (I've not used this
 in Mercurial, but I believe it's an extension).


hg transplant has been deprecated for a long time now. The correct command
for cherry-picking is hg graft.

I do sometimes miss the ability to easily cherry-pick the changes in a
single file. When grafting, you graft the entire revision, and then need to
revert individual files and amend the changeset if you don't want the graft
as-is. It's a bit messy, and could cause problems if you later do a merge
that includes the originally-grafted changeset on top of the amended
changeset (since the changes committed to the amended changeset will be
considered during the merge).

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

2014-08-28 Thread Chris Kaynor

On Thu, Aug 28, 2014 at 1:35 PM, Ervin Hegedüs airw...@gmail.com wrote:

 On Thu, Aug 28, 2014 at 12:34:18PM -0700, Chris Kaynor wrote:

 depending on what you are doing with the first two arguments to self._exit,
 the following might also work:

 def run(self):
 try:
 connect_to_db()
 do_another_thing()
 except:
 self._exit(*sys.exc_info())
 return True


 The first argument is a status, this is passed to the item, which passed
 to thread - so the thread sets that status, and the main loop knows,
 which item needs to pass to a thread. Eg. if the DB connection
 has failed, it needs to run again, at later. But if that item is
 parsed and finished (eg. table exists in db), then the item
 is deletable from the queue.


Mostly, I was wondering if you really need to differentiate types of
failures at that point. Would it be enough to merely know it worked vs
it failed? Even if you do need to behave differently, can you make the
decision based on the type of exception, rather than which stage you were
on? If so for either, you can remove the multiple try...except around
different statements, and put one big one around the entire run function.

This would likely simplify your handling code.


 One solution I did not mention before, but is plausible, is to
 monkey-patch/override the threading module to change the behavior
 of _bootstrap_inner or _bootstrap to behave differently. As these are on
 the Thread class, you could override them in your subclass or a base
 subclass (depending on the number of Thread subclasses you have) that
 behaves differently. Perhaps by making it call sys.excepthook. At one
 point, we discussed doing something similar at work as we normally print
 exceptions to custom streams that provide color formatting to make the
 exceptions easier to find and read (exception message printed in red,
 traceback in a dark red), as well as log.


 oh, that would be a big gun - and I don't feel that knowledge to
 made that with security and stability.

 I think this solution will enough at first time :), I didn't used
 anytime the threads (in serious project).


Yah, we never did this either, mostly due to the fact that then we'd have
to update our code if Python's code was updated. This can be quite
problematic, especially as the functions that would need to be overridden
are private, and thus not put to the same backwards compatibility standards
as most of Python's API.

What we did do, however, was wrap threading (in some cases) where we used a
thread pool where the actual run function was wrapped in our own error
handling, and called out to the desired function. Basically, most of our
threads went though common code that looked something like (simplified
here):

def run(self):
while True:
func, args, kwargs = self.queue.pop() # Actually, returned an
instance of a class which provided some join() and cancel() methods, among
others.
try:
func(*args, **kwargs)
except BaseExeception:
 # complex error handling here. Depending on conditions, this
might print the error, or might merely cache it in case the work item was
joined

Basically, the whole code block was a custom implementation of Python's
concurrent module, which we could not use as we had to support 2.6. It was
also written before 3.2 came out (if I remember the timing right).

Chris
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...


On 28/08/2014 22:25, Tim Delaney wrote:

On 29 August 2014 02:32, Tim Chase python.l...@tim.thechases.com
mailto:python.l...@tim.thechases.com wrote:


No, you wouldn't use hg pull nor git pull but rather git
cherry-pick or what Mercurial calls transplant (I've not used this
in Mercurial, but I believe it's an extension).

hg transplant has been deprecated for a long time now. The correct
command for cherry-picking is hg graft.

I do sometimes miss the ability to easily cherry-pick the changes in a
single file. When grafting, you graft the entire revision, and then need
to revert individual files and amend the changeset if you don't want the
graft as-is. It's a bit messy, and could cause problems if you later do
a merge that includes the originally-grafted changeset on top of the
amended changeset (since the changes committed to the amended changeset
will be considered during the merge).

Tim Delaney



Surely a lot of the hassle with version control systems could be avoided 
if people were to write bug free code in the first place? :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Thread terminate

2014-08-28 Thread Cameron Simpson


On 28Aug2014 12:02, Marko Rauhamaa ma...@pacujo.net wrote:

Ervin Hegedüs airw...@gmail.com:

at this time there is only one thread, as you wrote. I just try
to prepare it to higher load, when one thread will not enough...


Threads are a necessary evil when dealing with blocking function calls,
but evil they remain. [...snip...]


Feh. Threads are not evil. I wish people would not insist on this mantra.

Threads have a lot of potential to make managing your program harder if you 
don't exercise proper discipline. But if you pay attention and exercise care, 
they are a good approach for various circumstances, and far more lightweight 
than spawning distinct processes.


CHeers,
Cameron Simpson c...@zip.com.au

UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.   - Doug Gwyn
--
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 5:37 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 Chris Angelico ros...@gmail.com:

 What you're saying, though, is that there's something inherently
 special about file boundaries. You want files to be magically
 separable within a repo. Why? What's the significance of the file?

 Files do have that magic property. That's only an approximation, but it
 is a very accurate and fitting approximation. Developers have a strong
 tendency of collecting functions to files. More to the point,
 functionality may be split across multiple files, but a large repository
 is far too blunt an abstraction.

Very frequently I've moved patches around that affect just one
function in one file. There's some granularity at the file level, some
at the function level, some at the class level (if you have that
concept in your repo), etc, etc, etc. You'll find changes that affect
one of any of the above.

 In reality, it's highly unlikely that this simple fix is the only
 change that's ever occurred to that file, so I very much doubt that
 your proposal would even work.

 I have actually found the reverse to be true. Most fixes are very local,
 and in large repositories, most files don't experience any change for
 over numerous releases.

You're talking about a file having never changed across nine Python
releases, which happen roughly every year and a half. That's a file
that doesn't change for well over a decade, and now you want to
backport a change across all those releases. Even allowing for some
measure of exaggeration (CPython doesn't release patches for that many
versions), I'm still dubious that there hasn't been any sort of
sweeping change in that much time.

 With git/hg, the merge is exactly the same whether there've been
 changes to other files or changes to other parts of the same file,
 because file boundaries just aren't that special. This is basically a
 cherry-picking job;

 Yes, that's cherry-picking. You also have manual patching and manual
 editing. All methods are in use, manual editing in particular. That's
 because of the awkward repo-level abstraction.

Yes, cherry-picking happens. And in git, it's really easy. Ditto with
'hg graft', I'm sure, although I've never used it so Tim Delaney may
have to confirm that. If the file really hasn't changed, then the
cherry-pick will work.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP - get the regex module into stdlib

On Fri, Aug 29, 2014 at 7:15 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 Here it is in full, comments welcome.

 Please refer to http://bugs.python.org/issue2636

 That's all folks.

Ow, that doesn't look like a draft PEP to me, that looks like a
321-comment tracker issue. A PEP is usually a smidge more coherent
than that :)

My apologies, but I don't have time to read 300 comments saying This!
Is! Regex!. :):)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Media Conversion Using Python - Converting MP3 to Other Formats

Mark Lawrence breamore...@yahoo.co.uk writes:

 On 25/08/2014 16:28, Parth Trivedi wrote:
 Dear All,

 I need some help of yours. I want to convert audio in MP3 format to
 other formats including uncompressed raw format, WAV etc. and I am using
 python 2.7. Is there any built-in module I can use or any third party
 modules available ?

 Please help me on this. I would be very grateful.

 Thanks and Regards,
 Parth T.


 There are a number of extremely useful third party pieces of software
 available to help with this.  They are called search engines.  What
 have you tried with them, what problems did you have, what else do you
 need to know about them?

 If you'd have tried these rather obscure beasts, you might have found
 https://docs.python.org/2/py-modindex.html or
 https://pypi.python.org/pypi

 You can do the rest from there.

Curated lists [1] might be useful. If you don't know what you are searching
for then a search engine might return a wrong answer that you won't be
able to recognize as one (Catch-22).

[1] https://github.com/vinta/awesome-python#audio

Everybody needs to start somewhere.

Having said that, a search query: “python mp3” [2] returns useful
results for me.

[2] https://duckduckgo.com/?q=python+mp3


--
Akira

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading from sys.stdin reads the whole file in

Chris Angelico ros...@gmail.com writes:

 On Wed, Aug 27, 2014 at 4:37 PM, Steven D'Aprano st...@pearwood.info wrote:
 On Wed, 27 Aug 2014 08:29:20 +0300, Marko Rauhamaa wrote:

 Try flushing after each print.

 Doesn't help.

 It does, but insufficiently. If slurp.py is run under Py3, it works
 fine; or take Naoki's suggestion (although without the parens):

 import sys
 import time

 for line in iter(sys.stdin.readline, ''):
 print Time of input:, time.ctime(), line
 sys.stdin.flush()
 sys.stdout.flush()

 Then it works.

 ChrisA

It looks like this bug http://bugs.python.org/issue3907

`python -u out.py | python -u slurp.py`  could be used to avoid .flush()
calls everywhere.

Or reassign `sys.stdin = io.open(sys.stdin.fileno(), 'r', 1)` inside the
script.

http://stackoverflow.com/questions/107705/python-output-buffering


--
Akira

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP - get the regex module into stdlib

On Thu, Aug 28, 2014 at 6:10 PM, Chris Angelico ros...@gmail.com wrote:

 Ow, that doesn't look like a draft PEP to me, that looks like a
 321-comment tracker issue. A PEP is usually a smidge more coherent
 than that :)


From: http://legacy.python.org/dev/peps/pep-0001/

*PEP stands for Python Enhancement Proposal. A PEP is a design document
providing information to the Python community, or describing a new feature
for Python or its processes or environment. The PEP should provide a
concise technical specification of the feature and a rationale for the
feature.*

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 I don't think a working VC system needs to contain much more than that.
 Hg stays closer to the simple ideal than git, which really fails at
 being a black box. I don't see why git has staging or branches, for
 example.

I use short-lived development branches in git all the time. Start
working on a bug or feature, checkout a new branch specifically for
that work. Make changes, commit, make changes, commit, make changes,
commit, finish the feature, merge back into master. Once the branch is
merged back in, I just delete it. If something else comes up that I
need to work on while I'm on a feature branch, I can easily just do a
checkpoint commit and create a clean new branch from master to work
on. I never do any actual development work on master.

I find staging less useful, but it occasionally comes in handy when
I'm ready to commit some work but there are these other files I've
already changed that should really be part of the next commit.

 Or why can't I revert my changes to a file easily?

git checkout filename is not easy?

 The main problem with hg (and git) is the way cherrypicking is done.

 See these graphics:

  [1]   Product-Ver1
 |
 | bugfix
 |
 V  feature development
Product-Ver1' -- Product-Ver2'

feature development
  [2]   Product-Ver1 --- Product-Ver2
   |
   | bugfix
   |
cherry-picking V
Product-Ver1' -- Product-Ver2'


 My beef is this: The starting point and end result of [1] and [2] is
 identical. The version histories of Product-Ver1' and Product-Ver2'
 should usually also be identical. In hg and git, they are not. In CVS,
 they are not. In SVN, they are not.

Why should they be identical? If they are, then that means they're not
accurately reporting the actual history of the repository. I don't
understand why you would even want this.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

On Thu, Aug 28, 2014 at 10:17 AM, Marko Rauhamaa ma...@pacujo.net wrote:
 In large repositories (like CPython), you have independent modules with
 relatively independent (and typically linear) histories. Hg and git
 don't want to respect that independence.

 As I said before, the problem is alleviated or goes away if you split
 your large repositories into tiny repositories. Then, looking at the
 example above, you could have a collections repository. CPython 3.0 and
 3.9 might use the same version of the collections component. The bug
 would then be fixed in collections and both CPython 3.0 and 3.9 would
 simply update their component dependency to the latest and greatest
 collections.

So then to tag or branch a release I guess you would create the same
tag/branch on every single component subrepository?  And when you need
to checkout that old version you checkout every subrepository
independently. Sounds painful, but not unworkable.

But then what do you do if you need to checkout an intermediate
revision of the project that isn't tagged? This need does arise. You
can't just checkout the revision you want of a particular component,
because that old revision of that component may not be compatible with
the other components at HEAD. Even if it is, you're still checking out
a version of the repository that never actually existed. You can't
expect to reproduce behavior at a particular revision if you can't
even consistently recreate the revision.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

On Fri, Aug 29, 2014 at 12:20 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
 But then what do you do if you need to checkout an intermediate
 revision of the project that isn't tagged? This need does arise. You
 can't just checkout the revision you want of a particular component,
 because that old revision of that component may not be compatible with
 the other components at HEAD. Even if it is, you're still checking out
 a version of the repository that never actually existed. You can't
 expect to reproduce behavior at a particular revision if you can't
 even consistently recreate the revision.

See, that's where he and we fundamentally disagree. My view, your
view, git's view, and hg's view, is that all files in a repo are
intrinsically linked - that checking out an intermediate revision
means checking out that revision across the entire source tree.
Marko's view is that you check out an intermediate revision of the one
failing file. In my experience, you can't always say which is the
failing file, and even if you can, you can't just check out an old
version of that file and expect it to work with the new versions of
everything else, because there WILL be parallel changes - and lots of
them.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

python 3.4 use python-gcm can't import

2014-08-28 Thread Frank Liou

i just 

from gcm import GCM

then


Traceback (most recent call last):
File C:/Users/frank/Desktop/SinyiAPI/SinyiAPI.py, line 7, in module
from Model.Order import Order
File C:\Users\frank\Desktop\SinyiAPI\Model\Order.py, line 7, in module
from gcm.gcm import GCM
File frozen importlib._bootstrap, line 2237, in _find_and_load
File frozen importlib._bootstrap, line 2226, in _find_and_load_unlocked
File frozen importlib._bootstrap, line 1191, in _load_unlocked
File frozen importlib._bootstrap, line 1161, in _load_backward_compatible
File 
C:\Users\frank\untitled1\lib\site-packages\python_gcm-0.1.5-py3.4-win32.egg\gcm\__init__.py,
 line 4, in module
AttributeError: 'module' object has no attribute 'GCM'
it's don't let me import
i try so many way ex:
import gcm
from gcm.gcm import GCM
but still can't 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

2014-08-28 Thread Rustom Mody

On Friday, August 29, 2014 7:54:44 AM UTC+5:30, Chris Angelico wrote:
On Fri, Aug 29, 2014 at 12:20 PM, Ian Kelly wrote:
But then what do you do if you need to checkout an intermediate
revision of the project that isn't tagged? This need does arise. You
can't just checkout the revision you want of a particular component,
because that old revision of that component may not be compatible with
the other components at HEAD. Even if it is, you're still checking out
a version of the repository that never actually existed. You can't
expect to reproduce behavior at a particular revision if you can't
even consistently recreate the revision.

See, that's where he and we fundamentally disagree. My view, your
view, git's view, and hg's view, is that all files in a repo are
intrinsically linked - that checking out an intermediate revision
means checking out that revision across the entire source tree.
Marko's view is that you check out an intermediate revision of the one
failing file. In my experience, you can't always say which is the
failing file, and even if you can, you can't just check out an old
version of that file and expect it to work with the new versions of
everything else, because there WILL be parallel changes - and lots of
them.

There is a basic dogma in git-land that there are 2 gits: git-porcelain
and git git-plumbing. Since most people use the porcelain exclusively that
gets identified as git. But that is not the case. Here is Linus on the
intention of git as a (non-hierarchical) filesystem:

Linus Torvalds said:
| you can just see git as a filesystem - it's content-
| addressable, and it has a notion of versioning, but I really really
| designed it coming at the problem from the viewpoint of a _filesystem_
| person (hey, kernels is what I do), and I actually have absolutely _zero_
| interest in creating a traditional SCM system.

from http://marc.info/?l=linux-kernelm=111314792424707

Other instances of git-as-a-filesystem:

Using git plumbing for a backup system:

https://github.com/bup/bup

What Marko wants:
http://git.661346.n2.nabble.com/RFC-Zit-the-git-based-single-file-content-tracker-td1366498.html

Other attempts (all failed so far) at moving beyond the 40-year old
hierarchical paths
http://www.theguardian.com/technology/2006/jun/29/insideit.guardianweeklytechnologysection
--
https://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP - get the regex module into stdlib

2014-08-28 Thread Steven D'Aprano

Mark Lawrence wrote:

 Here it is in full, comments welcome.

I think you forgot to attach the document. Or your mail/news server deleted
it. If you attach it as a .txt file (preferably in ReST format) even the
most obnoxiously strict news server ought to accept it.

 Please refer to http://bugs.python.org/issue2636

I'm not sure that a PEP is needed. I thought Guido had already ruled that it
could be added to the std library provided the author (Matthew Barnett?
MRAB?) agreed.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python 3.4 use python-gcm can't import

On Thu, Aug 28, 2014 at 8:30 PM, Frank Liou fk2654159...@gmail.com wrote:
 i just

 from gcm import GCM

 then


 Traceback (most recent call last):
 File C:/Users/frank/Desktop/SinyiAPI/SinyiAPI.py, line 7, in module
 from Model.Order import Order
 File C:\Users\frank\Desktop\SinyiAPI\Model\Order.py, line 7, in module
 from gcm.gcm import GCM
 File frozen importlib._bootstrap, line 2237, in _find_and_load
 File frozen importlib._bootstrap, line 2226, in _find_and_load_unlocked
 File frozen importlib._bootstrap, line 1191, in _load_unlocked
 File frozen importlib._bootstrap, line 1161, in _load_backward_compatible
 File 
 C:\Users\frank\untitled1\lib\site-packages\python_gcm-0.1.5-py3.4-win32.egg\gcm\__init__.py,
  line 4, in module
 AttributeError: 'module' object has no attribute 'GCM'
 it's don't let me import
 i try so many way ex:
 import gcm
 from gcm.gcm import GCM
 but still can't

In the source at
https://github.com/geeknam/python-gcm/blob/master/gcm/gcm.py I see
that the second line is:

import urllib2

Since urllib2 no longer exists in Python 3, that's a clear sign that
this package supports Python 2 only.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: xml issue with Type 'bool' cannot be serialized

On Thu, Aug 28, 2014 at 2:58 PM, Noah noah-l...@enabled.com wrote:
 Hi list,

 I am not clear how to fix this issue.

 Traceback (most recent call last):
   File ./command.py, line 81, in module
 connect(host, USER, PASSWORD)
   File ./command.py, line 63, in connect
 dump = etree.tostring(xml_cmd)
   File lxml.etree.pyx, line 3165, in lxml.etree.tostring
 (src/lxml/lxml.etree.c:69414)
 TypeError: Type 'bool' cannot be serialized.


 here is snippets from the code



 --- code ---

 from jnpr.junos import Device
 from jnpr.junos.utils.config import Config
 from lxml import etree
 import jnpr.junos.exception
 import sys, os, time, re, getopt

 def connect(host, user, password):
 conn = Device(host=host, user=user, password=password).open()

 xml_cmd = ''
 xml_cmd = conn.rpc.get_configuration()
 dump = etree.tostring(xml_cmd)
 print dump

What is xml_cmd? Is it actually an ElementTree tree as required by
etree.tostring?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: hg, git, fossil, ...

Ian Kelly ian.g.ke...@gmail.com:

 On Wed, Aug 27, 2014 at 11:58 PM, Marko Rauhamaa ma...@pacujo.net wrote:
 I don't see why git has staging or branches, for example.

 I use short-lived development branches in git all the time. Start
 working on a bug or feature, checkout a new branch specifically for
 that work.

I do the same thing, but I use forks (git clone). Branches and forks
are conceptually almost identical, so why pollute your concept set with
extras?

 Or why can't I revert my changes to a file easily?

 git checkout filename is not easy?

Unfortunately, that's only half the story. If you have added but never
committed the file, the command is:

   git rm --cached filename

I've been in more complicated situations as well.

 Why should they be identical? If they are, then that means they're not
 accurately reporting the actual history of the repository. I don't
 understand why you would even want this.

I don't think the repository should have one, linear narrative. Rather a
large repository has numerous independent narratives.

To quote URL: http://en.wikipedia.org/wiki/Darcs:

   Darcs treats patches as first-class citizens. For the user, a
   repository can be seen as a set of patches, where each patch is not
   necessarily ordered with respect to other patches i.e. the set of
   patches is only a partially ordered set. In many cases patches can be
   independently transmitted between various repositories.

   Many branching, merging and cherry-picking operations that would
   require additional commands with snapshot-based systems like Git or
   Mercurial, can be directly done with Darcs with the usual ‘pull’ and
   ‘push’ commands.

   [...]

   Intuitively, a patch B depends on another patch A if A provides the
   content that B modifies. This means that patches that modify
   different parts of the code are considered, by default, independent.


Say you make a change to CPython's GC and I make a parallel change to the
deque implementation:

   common repo 
\  /  /conflict!
|\GC work /  /
| +--+  /
 \ /
  \   deque work  /
   +-+

Hg and git report a conflict and force me to merge, IOW, decide which
change comes earlier in the linear history.

A conflict and merge should be rare and hint at development process
problems. In hg and git, they are unavoidable, everyday occurrences. To
put it bluntly, hg and git do not support parallel development.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header

2014-08-28 Thread Bob Chen


Changes by Bob Chen 175818...@qq.com:


--
keywords: +patch
Added file: http://bugs.python.org/file36492/httplib.py.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22231
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header

2014-08-28 Thread Bob Chen


Bob Chen added the comment:

This patch ensures the url not to be unicode, so the 'join' would not cause 
error when there is utf-8 string behind.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22231
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22257] PEP 432: Redesign the interpreter startup sequence

2014-08-28 Thread Drekin


Changes by Drekin dre...@gmail.com:


--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22257
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data

2014-08-28 Thread Rolf Krahl


Rolf Krahl added the comment:

I'd like to support the request.  I have a use case where I definitely need 
this feature: I maintain a Python client for a scientific metadata catalogue, 
see [1] for details.  The client also features the upload of the data files.  
The files may come in as a data stream from another process, so my client takes 
a file like object as input.  The files may be large (several GB), so buffering 
them is not an option, they must get streamed to the server as they come in.  
Therefore, there is have no way to know the Content-length of the upload 
beforehand.

I implemented chunked transfer encoding in a custom module that monkey patches 
the library, see the attached file.  This works fine, but of course it's an 
awkward hack as I must meddle deeply into the internals of urllib and 
http.client to get this working.  This module is tested to work with Python 
2.7, 3.1, 3.2, 3.3, and 3.4 (for Python 3 you need to pass it through 2to3 
first).  I really would like to see this feature in the standard library in 
order to get rid of this hack in my package.  I would happy to transform my 
module into a patch to the library if such a patch would have a chance to get 
accepted.

[1]: https://code.google.com/p/icatproject/wiki/PythonIcat

--
nosy: +Rotkraut
Added file: http://bugs.python.org/file36493/chunkedhttp.py

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12319
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header


Changes by STINNER Victor victor.stin...@gmail.com:


--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22231
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value

2014-08-28 Thread Claudiu Popa


Changes by Claudiu Popa pcmantic...@gmail.com:


Added file: http://bugs.python.org/file36494/issue21527.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21527
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22292] pickle whichmodule RuntimeError

2014-08-28 Thread Attilio Di Nisio


Attilio Di Nisio added the comment:

A simple patch to freeze the list of sys.modules.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22292] pickle whichmodule RuntimeError


STINNER Victor added the comment:

 A simple patch to freeze the list of sys.modules.

Which patch?

--
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22292] pickle whichmodule RuntimeError

2014-08-28 Thread Attilio Di Nisio


Attilio Di Nisio added the comment:

diff -r fb3aee1cff59 Lib/pickle.py
--- a/Lib/pickle.py Wed Aug 27 09:41:05 2014 -0700
+++ b/Lib/pickle.py Thu Aug 28 10:59:37 2014 +0200
@@ -280,7 +280,7 @@
 module_name = getattr(obj, '__module__', None)
 if module_name is not None:
 return module_name
-for module_name, module in sys.modules.items():
+for module_name, module in list(sys.modules.items()):
 if module_name == '__main__' or module is None:
 continue
 try:

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22292
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22288] Incorrect Call grammar in documentation

2014-08-28 Thread Martijn Pieters


Martijn Pieters added the comment:

Fixed by revision 3ae399c6ecf6

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22288
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22293] mock could be less memory-intensive

2014-08-28 Thread James Westby


New submission from James Westby:

Hi,

I'm looking in to the memory usage of our testsuite, which does a fair amount of

  def setUp():
  patcher = patch.multiple(...)
  self.mock_whatever = patcher.start()
  self.addCleanup(patcher.stop)

or other ways of creating a mock and assigning it to an instance variable on a 
TestCase.

This means that by the end of a run, we have quite a lot of references to 
MagicMocks.

This then becomes the majority of the memory usage of the python process: (from 
meliae)

Total 1157176 objects, 1189 types, Total size = 327.1MiB (342972340 bytes)
 Index   Count   %  Size   % Cum Max Kind
 0  575750  49 198058000  57  57 344 MagicProxy
 1   49955   4  52034888  15  72  196888 dict
 2  124127  10  11881628   3  76  386477 str
 3   12997   1  11749288   3  79 904 type
 48225   0   9146200   2  821112 MagicMock
 5   66310   5   5282392   1  84   80056 tuple
 6   38161   3   4579320   1  85 120 function
 71503   0   3972281   1  86   49488 module
 8   28506   2   3648768   1  87 128 code
 9   25768   2   2869680   0  88   69168 list
10   12649   1   2803196   0  89   66356 unicode
112251   0   2503112   0  891112 ClientHandler
122228   0   2477536   0  901112 _patch
13   28223   2   2257840   0  91  80 instancemethod
142014   0   2239568   0  911112 BoundMethodWeakref
152003   0   2227336   0  921112 DummyCache
16   24681   2   2221112   0  93 792 _CallList
17   18555   1   1632840   0  93  88 weakref
181457   0   1550248   0  941064 Morsel
19   46258   3   1110192   0  94  24 int

The fact that each MagicMock creates 72 MagicProxies means that it is a 
significant chunk of memory, despite each being small.

John Arbash Meinel suggested setting __slots__ = ['name', 'parent'] on 
MagicProxy to reduce the memory usage of this simple object.

This helps with the memory usage:

Total 1140377 objects, 1189 types, Total size = 169.5MiB (177755867 bytes)
 Index   Count   %  Size   % Cum Max Kind
 0   47744   4  51347840  28  28  196888 dict
 1  574210  50  36749440  20  49  64 MagicProxy
 2  122020  10  11769659   6  56  386477 str
 3   12975   1  11729400   6  62 904 type
 48203   0   9121736   5  671112 MagicMock
 5   64125   5   5141368   2  70   80056 tuple
 6   36024   3   4322880   2  73 120 function
 71503   0   3972281   2  75   49488 module
 8   28506   2   3648768   2  77 128 code
 9   12643   1   2801540   1  79   66356 unicode
10   23634   2   2716064   1  80   69168 list
112251   0   2503112   1  821112 ClientHandler
12   28223   2   2257840   1  83  80 instancemethod
132014   0   2239568   1  841112 BoundMethodWeakref
142003   0   2227336   1  851112 DummyCache
15   24615   2   2214536   1  87 792 _CallList
16   18482   1   1626416   0  87  88 weakref
171457   0   1550248   0  881064 Morsel
18   46259   4   1110216   0  89  24 int
192496   0858624   0  89 344 ModelState

I'm going to go through and drop references so that these can get garbage 
collected, but making Mock less memory-intensive would probably be appreciated 
by its users.

Reducing the memory usage of the tiny MagicProxies would be good, but also if 
there is a way to reduce the number of them by not pre-assiging 72 of them for 
every MagicMock, when each is very unlikely to be used, then that would be good 
as well.

Thanks,

James

--
components: Library (Lib)
messages: 226017
nosy: james-w
priority: normal
severity: normal
status: open
title: mock could be less memory-intensive
type: resource usage
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22293
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data

2014-08-28 Thread Piotr Dobrogost


Piotr Dobrogost added the comment:

@Rotkraut

The truth is http in stdlib is dead.
Your best option is to use 3rd party libs like requests or urllib3.
Authors of these libs plan to get rid of httplib entirely; see Moving away 
from httplib (https://github.com/shazow/urllib3/issues/58)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12319
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22294] 2to3 consuming_calls: len, min, max, zip, map, reduce, filter, dict, xrange

2014-08-28 Thread Edward O


New submission from Edward O:

This is a patch for issues similar to #16573
With this patch, the following new tests are now unchanged:

r = dict(zip(s, range(len(s))), **d)
r = len(filter(attrgetter('t'), self.a))
r = min(map(methodcaller('f'), self.a))
max(map(node.id, self.nodes)) + 1 if self.nodes else 0
reduce(set.union, map(f, self.a))

Note that as part of the patch, the range transformation now calls the generic 
in_special_context in addition to the customized one (which. I guess, should be 
removed, but I didn't dare).

All existing tests pass, but the patterns used may not be strict enough, though 
I tried to stick to how it was done for other consuming calls.

M Lib/lib2to3/fixer_util.py
M Lib/lib2to3/fixes/fix_xrange.py
M Lib/lib2to3/tests/test_fixers.py

--
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3_more_consuming_calls.diff
hgrepos: 271
keywords: patch
messages: 226019
nosy: eddygeek
priority: normal
severity: normal
status: open
title: 2to3 consuming_calls:  len, min, max, zip, map, reduce, filter, dict, 
xrange
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36495/2to3_more_consuming_calls.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22294
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22274] subprocess.Popen(stderr=STDOUT) fails to redirect subprocess stderr to stdout


Akira Li added the comment:

Josh, on Windows, if at least one standard stream is replaced; all three
hStdInput, hStdOutput, hStdError handles are provided
(all-or-nothing). On POSIX, standard streams stdin (0), stdout (1),
stderr (2) are always inherited from the parent. Each stream can be
manipulated independently. c2pwrite=-1 is different from providing
c2pwrite=1 (STDOUT_FILENO) explicitly e.g., set_inheritable() call is
made after the fork() in the latter case.

My patch leads to dup2(fileno(stdout), STDERR_FILENO) when stdout is
None and stderr=STDOUT on POSIX i.e., it redirects stderr to the
inherited stdout (like 21 in the shell). It has no effect otherwise.

sys.__stdout__ is used so that the call fails sooner without fork() if
fileno(stdout) is not a valid file descriptor when python initializes
(daemon, GUI). __stdout__-based solution doesn't support a case when
fileno(stdout) is changed later in the program e.g., using freopen() on
some systems.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22274
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22293] unittest.mock: use slots in MagicMock to reduce memory footprint


Changes by STINNER Victor victor.stin...@gmail.com:


--
nosy: +michael.foord
title: mock could be less memory-intensive - unittest.mock: use slots in 
MagicMock to reduce memory footprint

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22293
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22294] 2to3 consuming_calls: len, min, max, zip, map, reduce, filter, dict, xrange

2014-08-28 Thread Edward O


Changes by Edward O edoubray...@gmail.com:


--
nosy: +benjamin.peterson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22294
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17620] Python interactive console doesn't use sys.stdin for input

2014-08-28 Thread Drekin


Drekin added the comment:

I have found another example of where the current interaction between readline 
and Python core lead to confussion. It started with following report on my 
package: https://github.com/Drekin/win-unicode-console/issues/2 .

Basically, IPython interactive console on Windows uses pyreadline package, 
which provides GNU readline functionality. To get input from user, it just 
calls input(prompt). Input calls readline both for writing prompt and reading 
the input. It interprets ANSI control sequences so colored prompt is displayed 
rather than garbage. And when user types, things like auto-completion work. 
sys.stdin is not used at all and points to standard object.

One easily gets the impression that since sys.stdin is bypassed, changing it 
doesn't mind, but it actually does. With changed sys.stdin, input() now uses it 
rather than readline and ANSI control sequences result in a mess. See 
https://github.com/ipython/ipython/issues/17#issuecomment-53696541 .

I just think that it would be better when input() allways delegated to 
sys.stdin and print() to sys.stdout() and this was the standard way to interact 
with terminal. It would then be the responsibility of sys.std* objects to do 
right thing – to read from file, to delegate to readline, to directly interact 
with console some way, to interpret or not the ANSI control sequences.

Solving issues like #1602 or #18597 or adding readline support to Windows would 
then be just matter of providing the right sys.std* implementation.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17620
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22244] load_verify_locations fails to handle unicode paths on Python 2

2014-08-28 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 97081a80f487 by Benjamin Peterson in branch '2.7':
fix load_verify_locations on unicode paths (closes #22244)
http://hg.python.org/cpython/rev/97081a80f487

--
nosy: +python-dev
resolution:  - fixed
stage:  - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22244
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21307] PEP 466: backport hashlib changes

2014-08-28 Thread Roundup Robot


Roundup Robot added the comment:

New changeset 3f73c44b1fd1 by Benjamin Peterson in branch '2.7':
PEP 466: backport hashlib algorithm constants (closes #21307)
http://hg.python.org/cpython/rev/3f73c44b1fd1

--
nosy: +python-dev
resolution:  - fixed
stage: needs patch - resolved
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21307
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12319] [http.client] HTTPConnection.putrequest not support chunked Transfer-Encodings to send data

2014-08-28 Thread Rolf Krahl


Rolf Krahl added the comment:

Thanks for the notice!  As far as I read from the link you cite, getting rid of 
the current httplib in urllib3 is planned but far from being done.  
Furthermore, I don't like packages with too many 3rd party dependencies.  Since 
my package is working fine with the current standard lib, even though using an 
ugly hack in one place, I'd consider switching to urllib3 as soon as the latter 
makes it into the standard lib.

I still believe that adding chunked transfer encoding to http.client and urllib 
in the current standard lib would only require a rather small change that can 
easily be done such that the lib remains fully compatible with existing code.  
Still waiting for feedback if such a patch is welcome.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12319
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21305] PEP 466: update os.urandom

2014-08-28 Thread Benjamin Peterson


Benjamin Peterson added the comment:

You should probably backport _PyRandom_Fini and cleanup the FD like a good 
citizen.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21305] PEP 466: update os.urandom

2014-08-28 Thread Alex Gaynor


Alex Gaynor added the comment:

This patch adds the finalizer to the backport -- not sure how I missed this the 
first time.

--
Added file: http://bugs.python.org/file36496/backport-urandom.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21305] PEP 466: update os.urandom


STINNER Victor added the comment:

@alex: please disable git format in your hgrc, so the bug tracker can create a 
review link to Rietveld for your patches.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21305] PEP 466: update os.urandom

2014-08-28 Thread Alex Gaynor


Alex Gaynor added the comment:

Victor -- new patch is in `hg` format.

--
Added file: http://bugs.python.org/file36497/backport-urandom.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21305] PEP 466: update os.urandom


STINNER Victor added the comment:

The third  backport-urandom.diff  (the one with the review link) looks good to 
me.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21305
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22277] webbrowser.py add parameters to suppress output on stdout and stderr