Re: socket issue with recv()
Arthur Clarck aclar...@gmail.com writes: ... The problem I have now is the following. I have a script to connect to some telecom service. The script is forking (parent/child) The child is only reading what comes from the remote server. Here the problematic code: total = '' while True: data = s.recv(1024) total += data if (data == ''): print 'remote site is closed' s.close() sys.exit() What is happening is that I got some datas from the remote site, Something like 'Contacting BH: ...' But directly followed by 'remote site is closed. Some services (such as older HTTP 1.0 services) are designed for one command per connection mode. This means, they answer a signle command and then close the connection. From what you describe, your service might belong to this class. In this case, you would need to open a new connection whenever you detect that the old connection was closed. -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple question
On Saturday, August 23, 2014 6:10:29 AM UTC-7, explode...@gmail.com wrote: Can some one explain why this happens: True, False = False, True print True, False False True Shush! That's one of Python's most closely-guarded secrets! Every politician on Earth will want to learn to program in Python after seeing that! -- https://mail.python.org/mailman/listinfo/python-list
Re: Simple question
On Sun, Aug 24, 2014 at 3:55 PM, John Ladasky john_lada...@sbcglobal.net wrote: Shush! That's one of Python's most closely-guarded secrets! Every politician on Earth will want to learn to program in Python after seeing that! Not really, the legal profession has known about this for centuries. (Princess Zara, presenting Sir Bailey Barre, Q.C., M.P.) A complicated gentleman allow to present, Of all the arts and faculties the terse embodiment, He's a great arithmetician who can demonstrate with ease That two and two are three or five or anything you please; An eminent Logician who can make it clear to you That black is white--when looked at from the proper point of view; A marvelous Philologist who'll undertake to show That yes is but another and a neater form of no. From Gilbert Sullivan's Utopia, Ltd, dating back to 1893. Python 2 continues this excellent tradition of permitting truth to be redefined at will, but Python 3 adopts the view of the narrow-minded pedant who still believes that two and two makes four. It's an opinionated language, and that helps you to avoid weirdnesses :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 08/23/2014 02:13 PM, Seymore4Head wrote:
On Sat, 23 Aug 2014 13:47:20 -0400, Seymore4Head
I found this function that I will be saving for later.
def make_it_money(number):
import math
return '$' + str(format(math.floor(number * 100) / 100, ',.2f'))
(I still need more practice to find out how it does what it does, but
I like the end result)
That's total nonsense and overkill! If you really want to do it with a separate function, using
old style:
def make_it_money(number):
return '$%.2f' % number
or using new style:
def make_it_money(number):
return '${:.2f}'.format(number)
But even these functions are unnecessary. Use either of these formatting methods directly in
the print() statement...
So I changed the line in question to:
print (repr(count).rjust(3), make_it_money(payment).rjust(13),
make_it_money(balance).rjust(14))
print('{:3d} ${:13.2f} ${:14.2f}'.format(count, payment, balance))
or
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
But please, please, PLEASE first go through a real tutorial, and WORK the examples to fix them
in your mind. Questions like these will all be covered there. And you'll learn the language as
a whole instead of trying to be spoon-fed isolated answers. It will be well worth your time.
The tutorial on the official Python web site is a good one (of course there are
many others)
docs.python.org/3/tutorial/index.html
It does appear that you're using Py3, but in case you're using Py2, change the '3' in that URL
to '2'.
(Print formatting is in section 7)
-=- Larry -=-
PS. Oops, my bad... I just double checked my suggestions, which left-justified the values, but
I see you want them right-justified (which keeps the decimal points lined up). This complicates
it a bit to keep the dollar-sign butted up against the value, and it makes it necessary to use
that make_it_money() function I said was unnecessary. But it's still unnecessary by using a
little different finagling... Try either of these versions:
print('{:3d} {:13s} {:14s}'.format(count,
'$' + str(round(payment, 2)), '$' + str(round(balance, 2
print('%3d %13s %14s' % (count, '$' + str(round(payment, 2)), '$' +
str(round(balance, 2
--
https://mail.python.org/mailman/listinfo/python-list
Best place to start of learning the raspberry pi
Hey I bought a raspberry pi, a bread board and all this electronics stuff and i really enjoy programming stuff in python and i have had a decent of practise with python. I really wont to get into making things with electronics(i have had a lot of practise with soldering as well) and then program them with python. Where is the best place to learn all this starting of from the beginning like the basics of electronics? -- https://mail.python.org/mailman/listinfo/python-list
Re: the output in reference of descriptor.
luofeiyu wrote: let me paste it again to make my question more clear: c2.d __get__() is called __main__.C2 object at 0x0297BE10 class '__main__.C2' __main__.C object at 0x0297BBA8 You have an instance c2. You do an attribute lookup on d, which is a descriptor, so d.__get__ is called. d.__get__ prints a status line, then returns d's self, which is an instance of C, not C2. Because you are in the interactive interpreter, the returned result is printed. Otherwise, it would be ignored. c2.d.a __get__() is called __main__.C2 object at 0x0297BE10 class '__main__.C2' __getattribute__() is called 'abc' This is the same as: temp = c2.d print(temp.a) which is the same as: temp = C() print(temp.a) Why the result of c2.d.a is not : __get__() is called __main__.C2 object at 0x0297BE10 class __main__.C2' __main__.C object at 0x0297BBA8 __getattribute__() is called 'abc' Why the` return self` in the __get__ method in class C does not work? Of course it works. It returns the instance of C, then Python looks up attribute a on that instance. Why there is no __main__.C object at 0x0297BBA8 in the output? Because you didn't print it. If you want to see that, you can do: temp = c2.d print(temp) print(temp.a) In the interactive interpreter, but nowhere else, the final result of each calculation is printed: py 1 + 2 3 py 1 + 2 + 3 + 4 + 5 15 You should not expect it to do this: py 1 + 2 + 3 + 4 + 5 3 6 10 15 Only the last result is printed. The same applies for the . operator: instance.a.b.c.d.e will only print the final result, not instance.a instance.a.b instance.a.b.c instance.a.b.c.d instance.a.b.c.d.e -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
On 2014-08-22 01:26, Chris Angelico wrote: On Fri, Aug 22, 2014 at 4:05 AM, Joseph Martinot-Lagarde joseph.martinot-laga...@m4x.org wrote: For information, Cython works with C++ now: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html. Now isn't that cool! Every time Cython gets discussed, I get a renewed desire to learn it. Trouble is, I don't have any project that calls for it - there's nothing I'm desperately wanting to do that involves both Python and C/C++. Anyone got any suggestions? :) Class-based, Python 3-compatible bindings for libtcod? http://doryen.eptalys.net/libtcod/ -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: Som confusion about the python library installation
Michael Torrie wrote: You could try Ubuntu 14.04. Don't forget to mention the hardware requirements for 14.04. Me thinks that a single core CPU and a medium class graphics card won't make the user happy with it. Wouldn't it be friendly to the resources of our world if at least some software was tended to as long as the hardware lived? Regards, H. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python vs C++
Le 23/08/2014 16:21, Chris Angelico a écrit : On Sun, Aug 24, 2014 at 12:02 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I don't know how fast lilypond is, but perhaps one could write an editor that wraps lilypond and invokes it in realtime to show the output in an adjacent panel, perhaps with a brief delay when the user stops typing. You theoretically could, but it'd be a bit awkward in places. It's not hard for a small textual change to result in a large visual change (eg if you use relative notes and add/remove an octave shift - it'll shift every subsequent note in the staff, which might mean more/less ledger lines needed, which will affect how much vertical space the staff needs, which will affect pagination...), so it'd often make for rather nasty flicker. Better to keep it explicit. ChrisA Frescobaldi (http://www.frescobaldi.org/) works exactly like this. It's like a latex IDE but for lilypond. It's quite powerfull and multiplatform. I use it exclusively now, it's way better that the bash script I used before that more or less rebuild the files when changed. This way you get the power of plain text and you have an almost instantaneous snapshot of the end result. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, 24 Aug 2014 00:04:29 -0700, Larry Hudson org...@yahoo.com
wrote:
On 08/23/2014 02:13 PM, Seymore4Head wrote:
On Sat, 23 Aug 2014 13:47:20 -0400, Seymore4Head
I found this function that I will be saving for later.
def make_it_money(number):
import math
return '$' + str(format(math.floor(number * 100) / 100, ',.2f'))
(I still need more practice to find out how it does what it does, but
I like the end result)
That's total nonsense and overkill! If you really want to do it with a
separate function, using
old style:
def make_it_money(number):
return '$%.2f' % number
or using new style:
def make_it_money(number):
return '${:.2f}'.format(number)
But even these functions are unnecessary. Use either of these formatting
methods directly in
the print() statement...
So I changed the line in question to:
print (repr(count).rjust(3), make_it_money(payment).rjust(13),
make_it_money(balance).rjust(14))
print('{:3d} ${:13.2f} ${:14.2f}'.format(count, payment, balance))
or
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
But please, please, PLEASE first go through a real tutorial, and WORK the
examples to fix them
in your mind. Questions like these will all be covered there. And you'll
learn the language as
a whole instead of trying to be spoon-fed isolated answers. It will be well
worth your time.
The tutorial on the official Python web site is a good one (of course there
are many others)
docs.python.org/3/tutorial/index.html
It does appear that you're using Py3, but in case you're using Py2, change the
'3' in that URL
to '2'.
(Print formatting is in section 7)
-=- Larry -=-
PS. Oops, my bad... I just double checked my suggestions, which
left-justified the values, but
I see you want them right-justified (which keeps the decimal points lined up).
This complicates
it a bit to keep the dollar-sign butted up against the value, and it makes it
necessary to use
that make_it_money() function I said was unnecessary. But it's still
unnecessary by using a
little different finagling... Try either of these versions:
print('{:3d} {:13s} {:14s}'.format(count,
'$' + str(round(payment, 2)), '$' + str(round(balance, 2
print('%3d %13s %14s' % (count, '$' + str(round(payment, 2)), '$' +
str(round(balance, 2
Thanks for sharing these. I tried every single one.
The first two you gave didn't format correctly (as you noted) but it
seems like they should have.
If I understand this one:
print('{:3d} ${:13.2f} ${:14.2f}'.format(count, payment, balance))
the ${:13.2f} part would have lined up correctly if the number had 13
digits before the decimal. The leading 0's were ignored.
The last two hit the spot when the last digit is not a 0. When the
last digit is a 0, it causes the decimals not to line up.
Tiny quirks like that can really be frustrating if you are trying to
deliver a polished product. Luck for me, I am not.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, 24 Aug 2014 00:04:29 -0700, Larry Hudson org...@yahoo.com
wrote:
On 08/23/2014 02:13 PM, Seymore4Head wrote:
On Sat, 23 Aug 2014 13:47:20 -0400, Seymore4Head
I found this function that I will be saving for later.
def make_it_money(number):
import math
return '$' + str(format(math.floor(number * 100) / 100, ',.2f'))
(I still need more practice to find out how it does what it does, but
I like the end result)
That's total nonsense and overkill! If you really want to do it with a
separate function, using
old style:
def make_it_money(number):
return '$%.2f' % number
or using new style:
def make_it_money(number):
return '${:.2f}'.format(number)
But even these functions are unnecessary. Use either of these formatting
methods directly in
the print() statement...
So I changed the line in question to:
print (repr(count).rjust(3), make_it_money(payment).rjust(13),
make_it_money(balance).rjust(14))
print('{:3d} ${:13.2f} ${:14.2f}'.format(count, payment, balance))
or
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
But please, please, PLEASE first go through a real tutorial, and WORK the
examples to fix them
in your mind. Questions like these will all be covered there. And you'll
learn the language as
a whole instead of trying to be spoon-fed isolated answers. It will be well
worth your time.
The tutorial on the official Python web site is a good one (of course there
are many others)
docs.python.org/3/tutorial/index.html
It does appear that you're using Py3, but in case you're using Py2, change the
'3' in that URL
to '2'.
(Print formatting is in section 7)
-=- Larry -=-
PS. Oops, my bad... I just double checked my suggestions, which
left-justified the values, but
I see you want them right-justified (which keeps the decimal points lined up).
This complicates
it a bit to keep the dollar-sign butted up against the value, and it makes it
necessary to use
that make_it_money() function I said was unnecessary. But it's still
unnecessary by using a
little different finagling... Try either of these versions:
print('{:3d} {:13s} {:14s}'.format(count,
'$' + str(round(payment, 2)), '$' + str(round(balance, 2
print('%3d %13s %14s' % (count, '$' + str(round(payment, 2)), '$' +
str(round(balance, 2
I almost moved, but I was looking at the print out again for this one:
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
I can't understand why the $%-13.2f is pushed against the first
column, but the $%-14.2f is not. It seems like the first case ignores
the leading 0s and the second case doesn't not.
--
https://mail.python.org/mailman/listinfo/python-list
Challenge to convert a simple IDL code into Python
Here is IDL code:
pro read_binary_file
file = 3B42RT.2014010318.7.bin
num_lon = 1440
num_lat = 480
data = {header: bytarr(num_lon*2), precip: intarr(num_lon,num_lat),
precip_error: intarr(num_lon,num_lat), $
source_of_estimate: bytarr(num_lon,num_lat), precip_uncal:
intarr(num_lon,num_lat)}
close, 1
openr, 1, file
readu, 1, data
close, 1
precip = swap_endian(data.precip)
print, precip
end
My attempt in Python is here:
fname = '3B42RT.2014010318.7.bin'
num_lon = 1440
num_lat = 480
with open(fname, 'rb') as fi:
contents = fi.read()
precip = struct.unpack_from(''+str(num_lon*num_lat)+'I',
contents, offset = num_lon*2)
precip = np.array(data,dtype=int)
precip data
But, the results obtained from two codes above are not same. The IDL code
is correct, but what is wrong with my python code?
Here is binary file I was working with:
ftp://trmmopen.gsfc.nasa.gov/pub/merged/3B42RT/3B42RT.2014010318.7.bin.gz
cleo
--
https://mail.python.org/mailman/listinfo/python-list
Re: Challenge to convert a simple IDL code into Python
On 08/24/2014 08:38 AM, Cleo Drakos wrote:
Here is IDL code:
|pro read_binary_file
file= 3B42RT.2014010318.7.bin
num_lon= 1440
num_lat= 480
data= {header: bytarr(num_lon*2), precip: intarr(num_lon,num_lat),
precip_error: intarr(num_lon,num_lat), $
source_of_estimate: bytarr(num_lon,num_lat), precip_uncal:
intarr(num_lon,num_lat)}
close, 1
openr, 1, file
readu, 1, data
close, 1
precip= swap_endian(data.precip)
print, precip
end|
My attempt in Python is here:
|fname= '3B42RT.2014010318.7.bin'
num_lon= 1440
num_lat= 480
with open(fname, 'rb') as fi:
contents= fi.read()
precip= struct.unpack_from(''+str(num_lon*num_lat)+'I', contents,
offset= num_lon*2)
precip= np.array(data,dtype=int)
precip data|
But, the results obtained from two codes above are not same. The IDL
code is correct, but what is wrong with my python code?
You are not giving us much to go on here.
First that's not legal Python . The |last line was probably meant to be
a print|||, but if you expect us to examine your code, you absolutely
*must* give us the actual code. Please cut and paste.
Second, saying it doesn't work us useless. Please tell us what the code
is supposed to do, and what it actually does, what you expected... If
there is output, cut and paste it. If there is an error traceback, cut
and paste it.
While you are at it, tell us what the IDL code does and cut and paste
it's output.
Gary Herron
Here is binary file I was working
with:ftp://trmmopen.gsfc.nasa.gov/pub/merged/3B42RT/3B42RT.2014010318.7.bin.gz
cleo
--
https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 23 August 2014 23:53, Chris Angelico ros...@gmail.com wrote: On Sun, Aug 24, 2014 at 8:47 AM, Joshua Landau jos...@landau.ws wrote: On 23 August 2014 23:31, Chris Angelico ros...@gmail.com wrote: I'd say never is too strong (there are times when it's right to put an import inside a function), but yes, in this case it should really be at the top of the function. But do any of them apply to import math? Yep. If you have only one function that will ever use it, and that function often won't ever be called, then putting the import inside the function speeds up startup. Anything that cuts down on I/O can give a dramatic performance improvement. python -c import time; a = time.time(); import math; b = time.time(); print(b-a) 0.0005981922149658203 *squints eyes* Is math not already imported by start-up? However, you won't need the import at all if you let the formatting function do the rounding for you. Can that floor? I'm not sure, dig into the format spec and see! FWIW, I haven't seen something that does so. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote: Is math not already imported by start-up? Why would it be? -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote: Is math not already imported by start-up? Why would it be? It's easy to check, by the way: $ python -c import sys; print(sys.modules['math']) Traceback (most recent call last): File string, line 1, in module KeyError: 'math' -- https://mail.python.org/mailman/listinfo/python-list
Re: Global indent
On 23 August 2014 22:55, Rustom Mody rustompm...@gmail.com wrote: On Sunday, August 24, 2014 2:27:56 AM UTC+5:30, Joshua Landau wrote: Ay, so is any editor with an API. I use Sublime mostly because it's pretty, fast and has a Python-based API. The only actual feature it has that some others don't is multiple selections, and even then a lot do. You mean this? http://emacsrocks.com/e13.html Yup. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote: Is math not already imported by start-up? Why would it be? It's easy to check, by the way: $ python -c import sys; print(sys.modules['math']) I don't mean into the global namespace, but imported by other modules (like the builtins) and thus cached, making instantiation trivial. -- https://mail.python.org/mailman/listinfo/python-list
Re: Som confusion about the python library installation
On 08/24/2014 03:17 AM, Heinz Schmitz wrote: Don't forget to mention the hardware requirements for 14.04. Me thinks that a single core CPU and a medium class graphics card won't make the user happy with it. Wouldn't it be friendly to the resources of our world if at least some software was tended to as long as the hardware lived? I think it will work just fine on a single core CPU with an older graphics card. Unity and Gnome 3 run fine on my old netbook that's single core Atom. So no worries there, except for people disliking Unity itself. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 24 August 2014 20:25, Joshua Landau jos...@landau.ws wrote:
On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote:
Is math not already imported by start-up?
I don't mean into the global namespace, but imported by other modules
(like the builtins) and thus cached, making instantiation trivial.
Although it doesn't seem to be:
python -c import sys; print('math' in sys.modules)
False
An even easier check:
python -c import time; a = time.time(); import math; b = time.time();
print(b-a)
0.0006012916564941406
python -c import math, time; a = time.time(); import math; b =
time.time(); print(b-a)
9.5367431640625e-06
I guess I'm just pessimistic. Even so, that's not much reason to hide
the import inside a function.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, Aug 24, 2014 at 1:25 PM, Joshua Landau jos...@landau.ws wrote: On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws wrote: Is math not already imported by start-up? Why would it be? It's easy to check, by the way: $ python -c import sys; print(sys.modules['math']) I don't mean into the global namespace, but imported by other modules (like the builtins) and thus cached, making instantiation trivial. sys.modules is the module cache. If it's not in there, then it hasn't been imported at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, Aug 24, 2014 at 1:29 PM, Joshua Landau jos...@landau.ws wrote:
On 24 August 2014 20:25, Joshua Landau jos...@landau.ws wrote:
On 24 August 2014 20:19, Ian Kelly ian.g.ke...@gmail.com wrote:
On Sun, Aug 24, 2014 at 1:17 PM, Ian Kelly ian.g.ke...@gmail.com
wrote:
On Sun, Aug 24, 2014 at 1:12 PM, Joshua Landau jos...@landau.ws
wrote:
Is math not already imported by start-up?
I don't mean into the global namespace, but imported by other modules
(like the builtins) and thus cached, making instantiation trivial.
Although it doesn't seem to be:
python -c import sys; print('math' in sys.modules)
False
That's the same check I posted, just using the in operator instead of a
straight lookup and raising an error.
An even easier check:
python -c import time; a = time.time(); import math; b =
time.time(); print(b-a)
0.0006012916564941406
Too dependent on system timings. I get:
$ python -c import time; a = time.time(); import math; b = time.time
(); print(b-a)
0.0
--
https://mail.python.org/mailman/listinfo/python-list
[ANN] Pylint 1.3.1 / Astroid 1.2.1 released
Hello! I'm happy to announce that Pylint 1.3.1 and Astroid 1.2.1 were released. These releases include some bugfixes with the new string formatting checker and a couple of crash fixes. Please note that Pylint 1.3.X is the last version of Pylint which supports Python 2.5 and 2.6. Enjoy! -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 24 August 2014 20:40, Ian Kelly ian.g.ke...@gmail.com wrote: That's the same check I posted, just using the in operator instead of a straight lookup and raising an error. I think I need to take a break from the internet. This is the second time in as many threads that I've responded with what I'm commenting on. *sigh* -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On 08/24/2014 08:12 AM, Seymore4Head wrote:
[snip]
I almost moved, but I was looking at the print out again for this one:
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
I can't understand why the $%-13.2f is pushed against the first
column, but the $%-14.2f is not. It seems like the first case ignores
the leading 0s and the second case doesn't not.
Let's break down the %-13.2f format code for example...
- Left justify (which was my original oversight)
13 Total field width, ie. 13 characters wide (default filler is space)
.2 Round to two decimal places -- that's 3 characters of the 13
(the decimal point plus the 2-digit fraction)
f The input is a floating point number
So the last column follows the 13-character wide second column...
(For illustration, I'm using '-' instead of the default space filler)
[-] [---] [] -- showing field widths
-12 $123.45--- $15.00-
Notice, the first field is right-justified by default.
(And that is not negative 12, the '-' is my pretend filler)
Helpful?
-=- Larry -=-
--
https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Sun, 24 Aug 2014 14:24:19 -0700, Larry Hudson org...@yahoo.com
wrote:
On 08/24/2014 08:12 AM, Seymore4Head wrote:
[snip]
I almost moved, but I was looking at the print out again for this one:
print('%3d $%-13.2f $%-14.2f' % (count, payment, balance))
I can't understand why the $%-13.2f is pushed against the first
column, but the $%-14.2f is not. It seems like the first case ignores
the leading 0s and the second case doesn't not.
Let's break down the %-13.2f format code for example...
- Left justify (which was my original oversight)
13 Total field width, ie. 13 characters wide (default filler is space)
.2 Round to two decimal places -- that's 3 characters of the 13
(the decimal point plus the 2-digit fraction)
f The input is a floating point number
So the last column follows the 13-character wide second column...
(For illustration, I'm using '-' instead of the default space filler)
[-] [---] [] -- showing field widths
-12 $123.45--- $15.00-
Notice, the first field is right-justified by default.
(And that is not negative 12, the '-' is my pretend filler)
Helpful?
-=- Larry -=-
Yes it is.
Thanks
--
https://mail.python.org/mailman/listinfo/python-list
Python makes Dilbert's list
For Sunday, Aug 24, 2014. http://www.dilbert.com/dyn/str_strip/0//000/20/2/5000/500/225504/225504.strip.sunday.gif -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: what do you get with 1 divide by 998001, interesting results
eyntk: I have a certain affection for your videos. I'm not sure they are useful to all, but maybe interesting to some. Kudos to all who try to spread their interest and knowledge. But this is a tough and very fair and generous crowd here I believe. Its probably better to listen and participate than to just announce. Or just announce and disappear! This place is more for interaction -- asking and responding, ... and debating. I don't know the rules for announcements. At any rate, if you feel you have something useful to offer, maybe you can figure out how to do that without given the impression that you are 'carpet bagging' (an american term). Using a name (even a nickname) makes you a person. Using a company name is kind of off-putting. If your group is more than you, then by all means, have all of you participate. No problem citing the group you are working with. Email addresses are more or less free, right? Joel Goldstick http://joelgoldstick.com This is my lat post to say that eyn2k is gone and you will see us as individuals not a groug or especially not on GG. Thank you everyone for your time, whether I have personally thought it positive or not we did learn alot and appreciate thought! Though I personally (Adam), am moving to the NSW coast in 4 weeks, and it will take four weeks probably before we can return. Thank you everyone for your time, Adam A *** Please do not respond, I would like to see this thread dissapear and reintroduce myself in 4 weeks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Python makes Dilbert's list
On Aug 24, 2014, at 7:18 PM, Terry Reedy tjre...@udel.edu wrote: For Sunday, Aug 24, 2014. http://www.dilbert.com/dyn/str_strip/0//000/20/2/5000/500/225504/225504.strip.sunday.gif — And at the risk of straying a bit OT, here is what Dilbert should have pointed his boss at wrt string theory. (And by the way - the physics is bang on.) http://www.npr.org/blogs/krulwich/2013/09/18/223716891/mama-mia-mama-mia-a-canadian-bohemian-rhapsodizes-about-string-theory -Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
Joshua Landau wrote:
python -c import sys; print('math' in sys.modules)
False
An even easier check:
python -c import time; a = time.time(); import math; b = time.time();
print(b-a)
0.0006012916564941406
python -c import math, time; a = time.time(); import math; b =
time.time(); print(b-a)
9.5367431640625e-06
I wouldn't exactly say that *two* calls to Python, each containing *five*
statements, followed by a visual comparison of two decimal numbers,
is even easier than a single call to Python, containing just two
statements :-)
Also, your timing test is open to interpretation and subject to interference
from the rest of your system, possibly even leading to completely the wrong
conclusion. If your system is sufficiently busy working on other tasks, the
two timings may be close together, or even reversed.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Mon, Aug 25, 2014 at 12:16 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Joshua Landau wrote:
python -c import sys; print('math' in sys.modules)
False
An even easier check:
python -c import time; a = time.time(); import math; b = time.time();
print(b-a)
0.0006012916564941406
python -c import math, time; a = time.time(); import math; b =
time.time(); print(b-a)
9.5367431640625e-06
I wouldn't exactly say that *two* calls to Python, each containing *five*
statements, followed by a visual comparison of two decimal numbers,
is even easier than a single call to Python, containing just two
statements :-)
I love this list. We can go off on a ridiculously long tangent, simply
because I said that it's only *usually* best to put imports at the top
of the file. We all agree that it normally is indeed best to hoist
them, and here we are, arguing over measurement methods on whether or
not there's ever any benefit to importing inside a function.
Yep, the Cheshire Cat was right. We're all mad here!
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: what do you get with 1 divide by 998001, interesting results
On Mon, Aug 25, 2014 at 10:04 AM, Everything You Need To Know ey...@outlook.com wrote: *** Please do not respond, I would like to see this thread dissapear and reintroduce myself in 4 weeks! Just so you know, asking people to not respond almost never works. :) On the flip side, asking for responses often doesn't work either... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
GO vs Python
I spent a few weeks looking at Go and have to say you can see a lot of Python's influence in Go, however my question to this list for others who are doing real work with Go and Python have you encountered any scenarios in which Go outmatched Python in terms of elegance or performance? --RB -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
Chris Angelico wrote: I love this list. We can go off on a ridiculously long tangent, simply because I said that it's only *usually* best to put imports at the top of the file. We all agree that it normally is indeed best to hoist them, and here we are, arguing over measurement methods on whether or not there's ever any benefit to importing inside a function. Yep, the Cheshire Cat was right. We're all mad here! Speak for yourself! I'm not here, I'm over there. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On Sun, Aug 24, 2014 at 9:36 PM, Rodrick Brown rodrick.br...@gmail.com wrote: I spent a few weeks looking at Go and have to say you can see a lot of Python's influence in Go, however my question to this list for others who are doing real work with Go and Python have you encountered any scenarios in which Go outmatched Python in terms of elegance or performance? --RB I use both, Python pays the bills, and I use it at work or on consulting gigs. for most things GO is faster, GO is compiled and that is a huge plus. the Go community is not nearly as large as pythons, there are loads more libraries and tools for python my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... Well I got scared, Go started to look attractive, because your no longer comparing GO to the entire python community, it is GO vs python 3... thats just my 2 cents, I like python and it pays my bills... but I hate the way python delt with the 2.x - 3.x, they dropped the ball. -- Sam Fourman Jr. -- https://mail.python.org/mailman/listinfo/python-list
Re: Working with decimals
On Mon, Aug 25, 2014 at 12:51 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Chris Angelico wrote: I love this list. We can go off on a ridiculously long tangent, simply because I said that it's only *usually* best to put imports at the top of the file. We all agree that it normally is indeed best to hoist them, and here we are, arguing over measurement methods on whether or not there's ever any benefit to importing inside a function. Yep, the Cheshire Cat was right. We're all mad here! Speak for yourself! I'm not here, I'm over there. Of course you are. But thanks to the wonders of quantum entanglement, your madness and my madness are intrinsically linked. It's like Unicode String Theory, in that nobody understands it, but it's really really important. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On Mon, Aug 25, 2014 at 12:57 PM, Sam Fourman Jr. sfour...@gmail.com wrote: my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... Well I got scared, Go started to look attractive, because your no longer comparing GO to the entire python community, it is GO vs python 3... If your Python 2 - Python 3 transition was almost a rewrite, then either your code is making horribly messy assumptions about bytes vs text everywhere (in which case the pain will happen, Py3 just forces you to deal with it up-front instead of burying your head in the sand and wishing funny characters would go away), or you did the transition wrongly. It's not a complete change of language. And, what libraries are you short of for Python 3? List them! Maybe they do exist now. Nearly everything important does, there are only a handful of large/popular 2.x-only modules. And if you talk about what's missing, you demonstrate the need for those ports, which might be the impetus someone needs to make it available. There's way too much vague FUD about Python 3. Everyone who complains does so with oh, there aren't many libraries for Python 3, not with PyFooBar isn't available for Python 3, which would actually be useful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Challenge to convert a simple IDL code into Python
Cleo Drakos wrote:
Thanks for your response.
The IDL code reads the given binary file, and prints out the data inside
it. The binary file structure is provided using the variable 'data' in the
IDL code. Then it print the only required data that in side the 'data
that is precip.
However when I tried to output the same using python code, it is not
producing the same result.
Sorry the last line of python code is print precip.
Python result is:
[ -1.e+00 -1.e+00 -1.e+00 ..., -2.09705293e+09
-2.09705293e+09 -2.09705293e+09]
IDL result is:
I am stunned that you have dumped nearly ten thousand lines of output in our
laps, and expect us to go through it all. I know Gary asked you to copy and
paste the output of the IDL code, but please be reasonable.
Are you able to generate a *smaller* data file, say with twenty values, and
demonstrate the same issue?
Let's go through your code, line by line.
Here is IDL code:
pro read_binary_file
What does this line pro read_binary_file do?
file = 3B42RT.2014010318.7.bin
I assume that just creates a variable called file with a string value.
num_lon = 1440
num_lat = 480
And again, presumably these is just the obvious two variables.
data = {header: bytarr(num_lon*2), precip: intarr(num_lon,num_lat),
precip_error: intarr(num_lon,num_lat), $
source_of_estimate: bytarr(num_lon,num_lat), precip_uncal:
intarr(num_lon,num_lat)}
Please explain in as much detail as you can what this does. I think this is
the critical part of the IDL code. We have to understand this precisely to
have any hope of translating it into Python.
close, 1
openr, 1, file
readu, 1, data
close, 1
And what these mysterious lines do?
precip = swap_endian(data.precip)
print, precip
end
And these lines. (Presumably print prints the variable, end is the end of
the program.)
My attempt in Python is here:
fname = '3B42RT.2014010318.7.bin'
num_lon = 1440
num_lat = 480
with open(fname, 'rb') as fi:
contents = fi.read()
precip = struct.unpack_from(''+str(num_lon*num_lat)+'I', contents,
offset = num_lon*2)
precip = np.array(data,dtype=int)
precip data
That last line is meant to be print data.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On Sun, Aug 24, 2014 at 10:07 PM, Chris Angelico ros...@gmail.com wrote: On Mon, Aug 25, 2014 at 12:57 PM, Sam Fourman Jr. sfour...@gmail.com wrote: my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... Well I got scared, Go started to look attractive, because your no longer comparing GO to the entire python community, it is GO vs python 3... If your Python 2 - Python 3 transition was almost a rewrite, then either your code is making horribly messy assumptions about bytes vs text everywhere (in which case the pain will happen, Py3 just forces you to deal with it up-front instead of burying your head in the sand and wishing funny characters would go away), or you did the transition wrongly. It's not a complete change of language. And, what libraries are you short of for Python 3? List them! Maybe they do exist now. Nearly everything important does, there are only a handful of large/popular 2.x-only modules. And if you talk about what's missing, you demonstrate the need for those ports, which might be the impetus someone needs to make it available. There's way too much vague FUD about Python 3. Everyone who complains does so with oh, there aren't many libraries for Python 3, not with PyFooBar isn't available for Python 3, which would actually be useful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list Thanks your your input chris, honestly it was the end of 2012 when I looked into a large py3 port for a client. I wrote a very large web project on Cheetah, and at the time there wasnt a Py3 port... Now I get that back when I wrote this code years before, I should have chose something else.. I remember doing some browsing around, and the pooco people that make jinja2 were not fans of python3(I forget the blog post), I got scared because a very large portion of my income was based on a single client... So since we were having scalability issues anyway, I moved them to GO, and it was a Win - Win, the GO standard lib does so much, and the scalability gains we received over python were so large, that we were able to reduce out AWS bill so much that I could hire another coder. I really like python, and we use it a ton, but a python like compiled language did wonders for us when we needed it most. Sam Fourman Jr. -- Sam Fourman Jr. -- https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On Mon, Aug 25, 2014 at 1:27 PM, Sam Fourman Jr. sfour...@gmail.com wrote: I remember doing some browsing around, and the pooco people that make jinja2 were not fans of python3(I forget the blog post), I got scared because a very large portion of my income was based on a single client... So since we were having scalability issues anyway, I moved them to GO, and it was a Win - Win, the GO standard lib does so much, and the scalability gains we received over python were so large, that we were able to reduce out AWS bill so much that I could hire another coder. There are some communities that, for some reason or other, dislike Python 3. That doesn't mean you have to. The Py2 model is a bit easier for boundary code (it lets you stuff your fingers in your ears and go LALALALALA there are no character encodings), but the Py3 model is way easier for application code. Text is text, no matter what characters it has in it. I really like python, and we use it a ton, but a python like compiled language did wonders for us when we needed it most. Sure. And your reduction of AWS bills sounds great. Just make sure you don't consume the entire extra coder's time doing things that Python would have done for you. Go's character model is inferior to Python 3's (or at least, it was last time I checked - stuff might have changed since then), so you may find yourself doing a lot of unnecessary work to make sure your code works correctly. Do be sure to test everything thoroughly, with characters from all over Unicode. Personally, when I want Python but faster, I go to Pike. Same character/string model (even the same style of internal representation), same broad object model, but a stronger focus on networking and on staying running 100% of the time. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Python and RTSP client
I have to read a RTSP stream in my program and return network status while doing so. Can anybody guide me through it? I have searched online, there are few repos on github, gstreamer python binding and others. Which one is better? Best Regards, Akshay Verma. -- https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On 8/24/2014 10:57 PM, Sam Fourman Jr. wrote: my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. idlelib comprises about 60 .py files. The 2.7 versus 3.4 versions are perhaps 99% the same. The one change affected most all files was 'Tkinter' to 'tkinter'. Some of the differences are not necessary for 2.7 code (as opposed to 2.5 versus 3.0). I believe most of the conversion was done with 2to3. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... The overall situation has improved in the last couple of years. But as Chris noted, what matters is the particular library or libraries one depends on, and if it is not available, whether 2to3 will convert it* or whether there is a replacement. * My daughter wanted to use PyBrain with 3.4. We ran it through 2to3 and while the doctest based tests did not work, the code itself seems to with little additional work. You later mentioned that GO is compiled. Python, of course, can be also, and there are various options, some still being improved. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue22236] Do not use _default_root in Tkinter tests
Roundup Robot added the comment: New changeset 32fdaf401e50 by Serhiy Storchaka in branch '2.7': Issue #22236: Tkinter tests now don't reuse default root window. New root http://hg.python.org/cpython/rev/32fdaf401e50 New changeset dd1dffe6f0d2 by Serhiy Storchaka in branch '3.4': Issue #22236: Tkinter tests now don't reuse default root window. New root http://hg.python.org/cpython/rev/dd1dffe6f0d2 New changeset 014060738f7f by Serhiy Storchaka in branch 'default': Issue #22236: Tkinter tests now don't reuse default root window. New root http://hg.python.org/cpython/rev/014060738f7f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22236 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22263] Add a resource for CLI tests
New submission from Serhiy Storchaka: Some modules have command-line interface (not always documented and tested). Their tests run a lot of subprocesses and requires long time, often longer than other tests of corresponding module. However command-line interface itself is much less important than Python interface. In the face of addition of more CLI tests it would be good to introduce new resource (commandline or cli) which will control the run of such tests. -- components: Tests messages: 225796 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka, zach.ware priority: normal severity: normal status: open title: Add a resource for CLI tests type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22263 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22236] Do not use _default_root in Tkinter tests
Serhiy Storchaka added the comment: Thanks Terry and Zachary for your reviews. I have committed the patch in haste because other issues depend on it. -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22236 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22260] Rearrange tkinter tests, use test discovery
Serhiy Storchaka added the comment: Currently Tkinter tests are splitted on four tests: test_tcl, test_tk, test_ttk_textonly, test_ttk_guionly. Ttk tests are separated because ttk is optional on Tk 8.4 and because ttk is separate large part of Tkinter. test_tcl and test_ttk_textonly are separated because they don't require GUI. On headless computer test_tk and test_ttk_guionly are reported as skipped at all, but test_tcl and test_ttk_textonly should run. It would be good to preserve this splitting and even improve it (test_variables does not require GUI and can be moved to test_tcl package). Tkinter tests are still incomplete and needs many test. To avoid obstacles for backporting new tests it is worth to apply these changes to all maintained branches. -- versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22260 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
Igor Pashev added the comment: errno is 25 (#define ENOTTY 25 /* Inappropriate ioctl for device */) It does not make sense to me to call unworkable ioctl() each time before other methods :-) I would consider adding a configure check for working ioctl() (but it won't work for cross compilation). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Ezio Melotti added the comment:
I think similar functions should be added in the unicodedata module rather than
the string module or as str methods. If I'm not mistaken this was already
proposed in another issue.
In C we already added macros like IS_{HIGH|LOW|}_SURROGATE and possibly others
to help dealing with surrogates but AFAIK there's no Python equivalent yet.
As for the specific constants/functions/methods you propose, IMHO the name
escaped_surrogates is not too clear. If it's a string of lone surrogates I
would just call it unicodedata.surrogates (and
.high_surrogates/.low_surrogates). These can also be used to build oneliner to
check if a string contains surrogates and/or to remove them.
clean has a very generic name with no hints about surrogates, and its purpose
is quite specific.
I'm also not a big fan of redecode. The equivalent calls to encode/decode are
not much longer and more explicit. Also having to redecode often indicates
that there's a bug before that should be fixed instead (if possible).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18814
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Nick Coghlan added the comment: The purpose of these changes it to provide tools specifically for working with surrogate escaped data, not for working with arbitrary lone Unicode surrogates. escaped_surrogates is not defined by the Unicode spec, it's defined by the behaviour of the surrogateescape error handler that lets us tunnel arbitrary bytes through str objects and reproduce them faithfully at the far end. On reflection, I think codecs would be a better home than string (as that's where the error handler is defined), but it doesn't belong in unicodedata. I'd be OK with changing the name of the clean function to clean_escaped_surrogates. Needing redecode is not a bug: it's baked into the WSGI spec in PEP . I would be OK with providing it in wsgiref rather than the codecs or string modules, but I think we should provide it somewhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22261] Document how to use Concurrent Build when using MsBuild
sbspider added the comment: Ok, thank you. Just wanted to confirm this, as I plan to help out on the code/documentation as well (and hence want to understand the process beforehand). I look forward to working on Python in the future. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22261 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Serhiy Storchaka added the comment: See also issue15795. It would be good to make shutil, zipfile and tarfile interfaces consistent. I think we need more graduated interface matching coretools. --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all --no-preserve=ATTR_LIST don't preserve the specified attributes This means that we should add preserve_mode, preserve_ownership, preserve_time, etc parameters. preserve_ownership should control also copying of suid/sgid/sticky bits. copy()'s defaults will be preserve_mode=True, preserve_ownership=False, preserve_time=False, copy2()'s defaults (corresponding to cp -p behavior) will be preserve_mode=True, preserve_ownership=True, preserve_time=True. -- nosy: +serhiy.storchaka versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows
Serhiy Storchaka added the comment: Could shutil experts please comment this patch? -- nosy: +christian.heimes, hynek, tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20912 ___ ___ 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
Changes by sbspider rajsho...@gmail.com: -- nosy: +sbspider ___ 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
[issue22194] access to cdecimal / libmpdec API
Stefan Krah added the comment: Antoine Pitrou rep...@bugs.python.org wrote: Who are those people? #16745 was opened by you :-) MvL, in #4555 (msg176486). Platform specific maybe, but no hack: I was thinking about storing the DSO handle in the PyModuleObject struct and add functions to lookup symbols. I'm attaching a diff for Linux -- It has been a while, but I'm rather certain that the corresponding scheme also worked on Windows (can't test now, my Windows VM is defunct). How does it work? I've tried to dlopen() and then dlsym() the _decimal file manually, it wouldn't work for private (e.g. mpd) symbols. Yes, the symbols would need to be public, see module_get_symbol.diff. That would leave the usual troublemakers AIX etc., which have sketchy support anyway. That sounds rather worrying. How about OS X? Why would that whole scheme be better than a capsule? I'm not sure about OS X, but I would be surprised if it did not work. To my limited knowledge, Capsules are slow, see also here (the penultimate paragraph): https://mail.python.org/pipermail/python-dev/2013-March/124481.html Stefan (Behnel), could you comment on the strategy that you had in mind? Is it similar to module_get_symbol.diff or entirely different? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Serhiy Storchaka added the comment: I agree with Ezio in all points. escaped_surrogates is inefficient for any purposes and incomplete. _match_surrogates can be created in more efficient way. clean() has too general and misleading name. redecode() looks just ridiculous, this cumbersome 4-argument function just combine two methods. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22034] posixpath.join() and bytearray
Roundup Robot added the comment: New changeset d9607a71456e by Serhiy Storchaka in branch '3.4': Issue #22034: Got rid of misleading error message for bytearray arguments in http://hg.python.org/cpython/rev/d9607a71456e New changeset db600c927b2b by Serhiy Storchaka in branch 'default': Issue #22034: Improve handling of wrong argument types in posixpath.join(). http://hg.python.org/cpython/rev/db600c927b2b -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22034] posixpath.join() and bytearray
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22034 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22207] Test for integer overflow on Py_ssize_t: explicitly cast to size_t
Serhiy Storchaka added the comment: I think there are too many changes. Here is simpler patch which get rid of all warnings in Objects/unicodeobject.c on my computer (gcc 4.6.3, 32-bit Linux). -- Added file: http://bugs.python.org/file36451/unicode_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22207 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Nick Coghlan added the comment: Guys, you're Python 3 unicode experts, already thoroughly familiar with how surrogateescape works. These features are not for you. The exact implementations don't matter. These need to exist, and they need to be documented with detailed explanations. People don't yet understand what the surrogateescape error handler is, and what it's for, or how to work with it. People consider surrogate escaping this weird mysterious thing. It's not - it's a really simple mapping of the 128 bytes with the high order bit set to a different part of the Unicode code space. These functions make it obvious. wsgiref.redecode is a natural consequence of the design of PEP - it makes sense to offer it there, as a hint that frameworks are likely to need it. We have a serious, serious, learnability problem around binary data handling in Python 3. It's nowhere near as bad as the learnability problem for text handling in Python 2, but it still needs more scaffolding to help people grow in understanding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22133] IDLE: Set correct WM_CLASS on X11
Serhiy Storchaka added the comment: Grepping idlelib for 'toplevel, there are about 10. Do all of the Toplevels get put on the activity bar? I would not expect that popups like calltip would. I don't know how dialogs and calltip popups behave on Gnome Shell. But I think we should do this at least for more or less long-lived windows such as stack viewer. On KDE when I added ``kw[class] = 'Idle3'`` to ListedToplevel constructor, console and editor windows are grouped on taskbar, and stack viewer is separated (without this line all three windows are in the same group). I expect that all ListedToplevels could be handled at once by adding the following as the first line of ListedToplevel.__init__. May be, but this is not so simple. To be robust we should handle both 'class' and 'class_' keywords (and may be even '-class'). What is wrong with simply adding classname to the Tk() call, as Roger suggested in #13553. This affects only WM_CLASS of root window (which is withdrawn right after creation in IDLE). Does KDE display 2 windows without name='Idle' in the toplevel call? Is this a KDE or tk bug? ``tk = Tk(className='Idle3')`` creates first (root) window and ``top = Toplevel(tk, class_='Idle3')`` creates second window. The className argument affects root window (and some other things) and the class argument affects Toplevel window. Another example: from tkinter import * tk = Tk(className='Firefox') top = Toplevel(tk, class_='Chromium-browser') Created two windows: one with title firefox and Firefox icon, and other with title firefox and Chromium icon. I argue that we should add className=Idle3 to every Tk constructor and class_=Idle3 to most (iv not every) Toplevel constructor. On Python 2 it should be Idle2 or Idle (not sure). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22133 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Ezio Melotti added the comment: That's why I think a function like redecode is a bad idea. With Python 2 I've seen lot of people blindingly trying .decode when .encode failed (and the other way around) whenever they were getting an UnicodeError (and the fact that decoding Unicode results in an encode error didn't help). I'm afraid that confused developers will try to (mis)use redecode as a workaround to attempt to fix something that shouldn't be broken in the first place, without actually understanding what the real problem is. There's really no excuse for developers not to know Unicode nowadays (Joel Spolsky said the same thing more than 10 years ago). IME people also tend to overestimate how difficult it is to understand Unicode. While it is true that you can go pretty deep down the rabbit hole, the basic concepts necessary for everyday use are pretty simple and straightforward. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17896] Move Windows external libs from src\..\ to src\externals
Mark Lawrence added the comment: I see that this has also been raised on #22262. As nobody has objected can't we just get on with it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17896 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
STINNER Victor added the comment: I propose to only call ioctl() once, and then remember (in a static variable) that it doesn't work and then always call fcntl(). I can work on a patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.fix_encoding
New submission from Nick Coghlan: The WSGI 1.1 standard mandates that binary data be decoded as latin-1 text: http://www.python.org/dev/peps/pep-/#unicode-issues This means that many WSGI headers will in fact contain *improperly encoded data*. Developers working directly with WSGI (rather than using a WSGI framework like Django, Flask or Pyramid) need to convert those strings back to bytes and decode them properly before passing them on to user applications. I suggest adding a simple fix_encoding function to wsgiref that covers this: def fix_encoding(data, encoding, errors=surrogateescape): return data.encode(latin-1).decode(encoding, errors) The primary intended benefit is to WSGI related code more self-documenting. Compare the proposal with the status quo: data = wsgiref.fix_encoding(data, utf-8) data = data.encode(latin-1).decode(utf-8, surrogateescape) The proposal hides the mechanical details of what is going on in order to emphasise *why* the change is needed, and provides you with a name to go look up if you want to learn more. The latter just looks nonsensical unless you're already familiar with this particular corner of the WSGI specification. -- messages: 225814 nosy: ncoghlan priority: normal severity: normal status: open title: Add wsgiref.fix_encoding type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_encoding
Nick Coghlan added the comment: This would be a better fit for the util submodule rather than the top level package. -- title: Add wsgiref.fix_encoding - Add wsgiref.util.fix_encoding ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_decoding
Nick Coghlan added the comment: Last tweak, since the purpose is to fix the original incorrect decoding to latin-1, this should be defined as a decoding operation: def fix_decoding(data, encoding, errors=surrogateescape): return data.encode(latin-1).decode(encoding, errors) -- title: Add wsgiref.util.fix_encoding - Add wsgiref.util.fix_decoding ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Nick Coghlan added the comment:
The redecode thing is a distraction from my core concern here, so I've split
that out to issue #22264, a separate RFE for a wsgiref.fix_encoding function.
For this issue, my main concern is the function to *clean* a string of escaped
binary data, so it can be displayed easily, or otherwise purged of the escaped
characters. Preserving the data by default is good, but you have to know a
*lot* about how Python 3 works in order to be able figure out how to clean it
out.
For that, not knowing Unicode in general isn't the problem: it's not knowing
PEP 383. If we forget the idea of exposing the constant with the escaped values
(I agree that's not very useful), it suggests codecs.clean_surrogate_escapes
as a possible name:
# Helper to ensure a string contains no escaped surrogates
# This allows it to be safely encoded without surrogateescape
_extended_ascii = bytes(range(128, 256))
_escaped_surrogates = _extended_ascii.decode('ascii',
errors='surrogateescape')
_match_escaped = re.compile('[{}]'.format(_escaped_surrogates))
def clean_surrogate_escapes(s, repl='\ufffd'):
return _match_escaped.sub(repl, s)
A more efficient implementation in C would also be fine, this is just an easy
way to define the exact semantics.
(I also just noticed that unlike other error handlers, surrogateespace and
surrogatepass do not have corresponding codecs.surrogateescape_errors and
codecs.surrogatepass_errors functions)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18814
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Serhiy Storchaka added the comment:
What problem is purposed to solve clean_surrogate_escapes()? Could you please
provide user scenario or two?
Possible alternative implementation is:
def clean_surrogate_escapes(s):
return s.encode('utf-8', 'surrogatepass').decode('utf-8', 'replace')
It can be faster for some data (for mostly ASCII with rare surrogates it is
superfast). For other data 'utf-16' can be better choice.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18814
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_decoding
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Library (Lib), Unicode nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_decoding
Serhiy Storchaka added the comment: Could you please provide an example how this helper will improve stdlib or user code? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_decoding
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22259] fdopen of directory causes segmentation fault
Brian Kearns added the comment: Updated to use assertEqual -- Added file: http://bugs.python.org/file36452/fdopen-directory.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22259 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22259] fdopen of directory causes segmentation fault
Changes by Brian Kearns bdkea...@gmail.com: Removed file: http://bugs.python.org/file36450/fdopen-directory.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22259 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Antoine Pitrou added the comment: Le 24/08/2014 04:56, Stefan Krah a écrit : I'm not sure about OS X, but I would be surprised if it did not work. To my limited knowledge, Capsules are slow, see also here (the penultimate paragraph): They are slow if you have to lookup and unwrap a capsule every time you use it. But the way it would work for _decimal (and the way it already works for _datetime), AFAIK, would be different: you would look up the capsule API structure once and then simply dereference function pointers from that structure. You can actually take a look at Include/datetime.h and see if the approach would work. See especially: /* Define global variable for the C API and a macro for setting it. */ static PyDateTime_CAPI *PyDateTimeAPI = NULL; #define PyDateTime_IMPORT \ PyDateTimeAPI = (PyDateTime_CAPI *)PyCapsule_Import(PyDateTime_CAPSULE_NAME, 0) which encourages a once-in-a-process-lifetime API lookup pattern. I don't think a hand-coded dlsym()-based approach can be any significantly faster. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18814] Add tools for cleaning surrogate escaped strings
Nick Coghlan added the comment: My main use case is for passing data to other applications that *don't* have their Unicode handling in order - I want to be able to use Python to do the data scrubbing, but at the moment it requires intimate knowledge of the codec error handling system to do it. (I had never even heard of surrogatepass until this evening) Situation: What I have: data decoded with surrogateescape What I want: that same data with all the surrogates gone, replaced with either the Unicode replacement character or an ASCII question mark (which I want will depend on the exact situation) Assume I am largely clueless about the codec system. I know nothing beyond the fact that Python 3 strings may have smuggled bytes in them and I want to get rid of them because they confuse the application I'm passing them to. The concrete example that got me thinking about this again was the task of writing filenames into a UTF-8 encoded email, and wanting to scrub the output from os.listdir before writing the list into the email (s/email/web page/ also works). For issue #22016 I actually suggested doing this as *another* codec error handler (surrogatereplace), but Stephen Turnbull convinced me this original idea was better: it should just be a pure data transformation pass on the string, clearing the surrogates out, and leaving me with data that is identical to that I would have had if surrogatereplace had been used instead of surrogateescape in the first place. As errors='replace' already covers the ASCII ? replacement case, that means your proposed redecode based solution would cover the rest of my use case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18814 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16808] inspect.stack() should return list of named tuples
Antoine Pitrou added the comment: It seems like this patch had been overlooked. I refreshed it for 3.5, added a couple tests, and pushed it. Thank you, Daniel! -- assignee: meador.inge - nosy: +pitrou resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16808 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16808] inspect.stack() should return list of named tuples
Roundup Robot added the comment: New changeset d03730abd2f6 by Antoine Pitrou in branch 'default': Issue #16808: inspect.stack() now returns a named tuple instead of a tuple. http://hg.python.org/cpython/rev/d03730abd2f6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16808 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Stefan Krah added the comment: Ah yes, the array of function pointers is directly accessible. I did not look close enough -- reading the word spam 100x in the docs always makes me skim the text. ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Antoine Pitrou added the comment: MvL, in #4555 (msg176486). Ok, I'm cc'ing Martin then :-) Note RTLD_LOCAL seems to be the default with dlopen(). Now I don't know how that behaves when you have a chained library loading, e.g.: Apache -- dlopen(Python dll) -- dlopen(_decimal dll) _decimal is an interesting case, since AFAIK with other C extensions it isn't really interesting to access the underlying C library, but with _decimal not being able to access libmpdec would force _decimal to duplicate a large part of the libmpdec API with a PyDec prefix added in front of it. (which means that, perhaps, the answer is to make the mpd_ prefix configurable with a #define?) -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Stefan Krah added the comment: Antoine Pitrou rep...@bugs.python.org wrote: (which means that, perhaps, the answer is to make the mpd_ prefix configurable with a #define?) I don't know 100% what you have in mind, but Debian and Arch already ship --with-system-libmpdec, so only the mpd_* functions would be available. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22194] access to cdecimal / libmpdec API
Antoine Pitrou added the comment: Le 24/08/2014 11:11, Stefan Krah a écrit : Antoine Pitrou rep...@bugs.python.org wrote: (which means that, perhaps, the answer is to make the mpd_ prefix configurable with a #define?) I don't know 100% what you have in mind, but Debian and Arch already ship --with-system-libmpdec, so only the mpd_* functions would be available. Ah... that probably kills the idea then. I was thinking in the context of a private-built libmpdec and had forgotten about that possibility. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22264] Add wsgiref.util.fix_decoding
Nick Coghlan added the comment: Current cryptic incantation that requires deep knowledge of the encoding system to follow: data = data.encode(latin-1).decode(utf-8, surrogateescape) Replacement that is not only more self-documenting, but also gives you something specific to look up in order to learn more: data = wsgiref.util.fix_encoding(data, utf-8) As a WSGI server, the standard library code mostly does this in the other direction, converting data from its original web server provided encoding *to* latin-1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22264 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22259] fdopen of directory causes segmentation fault
Roundup Robot added the comment: New changeset 6e67a0394957 by Benjamin Peterson in branch '2.7': don't segfault when trying to fdopen() a fd for a dir (closes #22259) http://hg.python.org/cpython/rev/6e67a0394957 -- nosy: +python-dev resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22259 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for python -m module in help
Miki Tebeka added the comment: New patch with handling of zip files. -- Added file: http://bugs.python.org/file36453/prog2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22234] urllib.parse.urlparse accepts any falsy value as an url
Antti Haapala added the comment: On Python 2.7 urlparse.urlparse, parsing None, () or 0 will throw AttributeError because these classes do not have any 'find' method. [] has the find method, but will fail with TypeError, because the built-in caching requires that the input be hashable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22234 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly
Dan O'Reilly added the comment: So, concurrent.futures is fixed now. Unless someone wants to patch multiprocessing.Pool, I am closing this issue. I realize I'm 3 years late on this, but I've put together a patch for multiprocessing.Pool. Should a process in a Pool unexpectedly exit (meaning, *not* because of hitting the maxtasksperchild limit), the Pool will be closed/terminated and all cached/running tasks will return a BrokenProcessPool. These changes also prevent the Pool from going into a bad state if the initializer function raises an exception (previously, the pool would end up infinitely starting new processes, which would immediately die because of the exception). One concern with the patch: The way timings are altered with these changes, the Pool seems to be particularly susceptible to issue6721 in certain cases. If processes in the Pool are being restarted due to maxtasksperchild just as the worker is being closed or joined, there is a chance the worker will be forked while some of the debug logging inside of Pool is running (and holding locks on either sys.stdout or sys.stderr). When this happens, the worker deadlocks on startup, which will hang the whole program. I believe the current implementation is susceptible to this as well, but I could reproduce it much more consistently with this patch. I think its rare enough in practice that it shouldn't prevent the patch from being accepted, but thought I should point it out. (I do think issue6721 should be addressed, or at the very least internal I/O locks should always reset after forking.) -- nosy: +dan.oreilly Added file: http://bugs.python.org/file36454/multiproc_broken_pool.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for python -m module in help
paul j3 added the comment: The patch tests assume the test is being run in a particular way: python -m unittest ... But I often use python3 -m unittest ... or python3 test_argparse.py both of which fail these tests. Testing this change might be more difficult than implementing it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22265] fix reliance on refcounting in test_itertools
New submission from Brian Kearns: The test fails on Python implementations with non-refcounted GCs without this line. -- files: test_itertools.patch keywords: patch messages: 225835 nosy: bdkearns priority: normal severity: normal status: open title: fix reliance on refcounting in test_itertools type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36455/test_itertools.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22265 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22266] fix reliance on refcounting in tarfile.gzopen
New submission from Brian Kearns: tarfile.gzopen relies on refcounting to close the fileobj when the fileobj is created during the call to gzopen (when it is not passed in). Since the fileobj is created outside of GzipFile, GzipFile does not take responsibility for closing the fileobj (so no one does, aside from the GC, which leads to unexpected behavior when using a non-refcounted GC). This is fixed by having GzipFile open the fileobj itself, so it does take responsibility for closing it when necessary. The same approach is taken in tarfile.py in py3k branch. -- files: tarfile.patch keywords: patch messages: 225836 nosy: bdkearns priority: normal severity: normal status: open title: fix reliance on refcounting in tarfile.gzopen type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36456/tarfile.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22266 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22265] fix reliance on refcounting in test_itertools
Brian Kearns added the comment: Should go on py3k branches too... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22265 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22265] fix reliance on refcounting in test_itertools
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22265 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22266] fix reliance on refcounting in tarfile.gzopen
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22266 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22265] fix reliance on refcounting in test_itertools
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22265 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for python -m module in help
paul j3 added the comment: What if the package is run without `-m`? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22240 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22267] fix reliance on refcounting in test_weakref
New submission from Brian Kearns: The test fails on Python implementations with non-refcounted GCs without these lines. Should go on py3k branches also. -- files: test_weakref.patch keywords: patch messages: 225839 nosy: bdkearns priority: normal severity: normal status: open title: fix reliance on refcounting in test_weakref type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36457/test_weakref.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22267] fix reliance on refcounting in test_weakref
Alex Gaynor added the comment: Perhaps these should use the gc_collect function in test_support? -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22267] fix reliance on refcounting in test_weakref
Brian Kearns added the comment: Possibly. But if so then one would argue there are plenty of other instances where gc_collect should be used, both within test_weakref and the rest of the test suite. Chose gc.collect here as it was used all over test_weakref.py, gc_collect never being used, and it fixed the test on PyPy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22267 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22268] mrohasattr and mrogetattr
New submission from Gregory Salvan: It's a small refactoring. Lurking at collections.abc I found a lot of: any(attr in B.__dict__ for B in C.__mro__) also repeated in typing.py of mypy: https://github.com/JukkaL/mypy/blob/master/lib-typing/3.2/typing.py#L117 It seems to be a common operation to check or get an attribute from mro in abc, so I thought it could help to have dedicated functions to enhance readability. (see patch e.g. Hash.__subclasshook__ takes 1 line intead of 7...) -- components: Library (Lib) files: mroattr.patch keywords: patch messages: 225842 nosy: Gregory.Salvan priority: normal severity: normal status: open title: mrohasattr and mrogetattr type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36458/mroattr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22268 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22269] Resolve distutils option conflicts with priorities
New submission from Min RK: Background: Some Python distros (OS X, Debian, Homebrew, others) want the default installation prefix for packages to differ from sys.prefix. OS X and Debian accomplish this by patching distutils itself, with special cases like `if sys.prefix == '/System/Library/...': actually_do_something_else()`. Homebrew accomplishes this by writing a `distutils.cfg` with: [install] prefix = /usr/local The distutils.cfg approach is certainly simpler than shipping a patch, but has its own problems, because distutils doesn't differentiate the *source* of configuration options when resolving conflicts. That means that you can't do `python setup.py install --user` because it fails with the error can't combine user with prefix, ... without also specifying `--prefix=''` to eliminate the conflict. Proposal: I've included a patch for discussion, which uses the fact that the option_dict tracks the source of each option, and keeps track of the load order of each. In the case of an option conflict, the option that came from the lower priority source is unset back to None. If they come from the same source, then the same conflict error message is displayed as before. Even if this patch is rejected as madness, as I expect it might be, official recommendations on how to address the root question of `sys.prefix != install_prefix` would be appreciated. -- components: Distutils files: distutils_conflict.patch keywords: patch messages: 225843 nosy: dstufft, eric.araujo, minrk priority: normal severity: normal status: open title: Resolve distutils option conflicts with priorities 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/file36459/distutils_conflict.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21480] A build now requires...
paul j3 added the comment:
I ran into a (possibly) related compiling problem (for 'default', 3.5 branch)
in `asdl.py`:
class Module(AST):
def __init__(self, name, dfns):
...
self.types = {type.name: type.value for type in dfns}
The dictionary comprehension syntax means this can only be run with Python3.
With an older Ubuntu installation, python2.6 is my default 'python'.
I had to make a local `python3` link to an earlier development python3.4 to get
around this.
--
nosy: +paul.j3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21480
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
