Re: Python Makefiles... are they possible?
One thing we do in our Makefiles is find . -name '*.pyc' | xargs rm. It avoids all sorts of nasty and hard to track down bugs (consider what happens if you move a .py file from one place in your source tree to another and leave the old .pyc behind). How often do you move files around in the source tree? Meanwhile, *every* time you run make, you take a performance hit on every Python module in your project, whether it has moved or not. Seems to me like a fairly heavy-handed response for something quite rare, but I suppose that depends on how often you run make. If the performance hit doesn't really matter. Then simply walk the build tree, compare time date stamps, anything that doesn't match up in the make directory, gets deleted. Anything that has different Date Created / Date Modified time from the build tree match, get's deleted. This way, we are preserving any files that should be identical. But there should be some mechanism documented to forcibly clear the build cache. - Benjamin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Makefiles... are they possible?
On 02/13/2013 12:54 AM, Steven D'Aprano wrote: On Tue, 12 Feb 2013 20:06:35 -0500, Roy Smith wrote: One thing we do in our Makefiles is find . -name '*.pyc' | xargs rm. It avoids all sorts of nasty and hard to track down bugs (consider what happens if you move a .py file from one place in your source tree to another and leave the old .pyc behind). How often do you move files around in the source tree? Meanwhile, *every* time you run make, you take a performance hit on every Python module in your project, whether it has moved or not. Seems to me like a fairly heavy-handed response for something quite rare, but I suppose that depends on how often you run make. That's why I assumed that his command was triggered by the make clean command. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Makefiles... are they possible?
In article 511b2a7c$0$11096$c3e8...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 12 Feb 2013 20:06:35 -0500, Roy Smith wrote: One thing we do in our Makefiles is find . -name '*.pyc' | xargs rm. It avoids all sorts of nasty and hard to track down bugs (consider what happens if you move a .py file from one place in your source tree to another and leave the old .pyc behind). How often do you move files around in the source tree? It has happened enough times to make us look for a solution. Which means more than once. Meanwhile, *every* time you run make, you take a performance hit on every Python module in your project, whether it has moved or not. The performance hit is minimal. The hours of tearing out your hair trying to figure out why bizarre things are happening is not. Another solution would be if there was a flag you could give to Python to tell it, Only import a .pyc if the corresponding .py file exists. It's already checking to see if the .py is newer, so this wouldn't even cost anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Monitoring updating directory for image for GUI
ciscorucin...@gmail.com writes: WOW...I am thinking that all of this was actually unnecessary, I don't think I need a Queue, or List / Stack, or any traversal of the file system to accomplish this!! I only need one image displayed at a time and don't care about them after a newer image is generated. So my prototype of just replacing the image over and over again SHOULD suffice. All I need the for the monitor now is to grab the image file (that might have or might not have been updated by Lilypond) at set amount of times and refresh the GtkImage object. The only reason why I originally suggested using multiple files was because I wanted to make sure that I had to most recent image and I was not sure if the threads would guarantee that. So my only remaining question (for now) is... I'm I guaranteed that if I have threads 1...n, that were all started in **quick** succession to call an OS command on Lilypond, that if I replaced the image file being generated with the completion of each thread that I would end up with the final image being from thread n...and that if I were able to update the GUI in a fast enough fashion, that I would see the images being displayed on the screen from 1 to n without anything being out of place? No, I don't think so. You have no guarantee that the images will be completed in the same order as the threads are started. All of my tests have shown that seems to be a reasonable assumption, but I need to know for sure. If that was the case were I am not guaranteed that, then when a user decides to stop the stream I could resend the note stream that I have saved on my end to Lilypond one last time to guarantee that all of the notes are displayed. So I would only create one image location at images\sheetMusic.png and that file would be continuously updated as new notes are streamed in. My monitor class (might be a legacy component now) would basically look for that one image - images\sheetMusic.png, grab it, and update the GUI at an interval that is easy on the eyes (maybe a half second for example). It could very well be that the image is being constructed and therefore does not yet contain a complete image when you want to display it. Could there be a problem where the image is being updated, so the OS deletes the image, and my program tries to update the image but cannot find it, and the OS reassigns that file location to that previous file location and name? Maybe it can find it, but it might not be a valid image Let me know what you thing or if anything is confusing you. Thanks for the comments so far! I think the way I described it in my previous message still gives you the easiest solution: I'll repeat it here in case you missed it. I suppose you have two threads, one for producing the music by calling Lilypond, and one for displaying the generated images. Because it is multithreaded you should use a Queue from the module Queue(Python2)/queue(Python3) to communicate between the threads. Producing thread: send note to Lilypond wait until PNG file is generated (Lilypond completed) Q.put(filename) Displaying thread: while True: fn = Q.get() # this will block until a filename is available # now check if there is more in the queue while True: try: fn = Q.get_nowait # here we got a newer one except Empty: break # stop the inner loop display the image in fn. In this way you always display the most recent one. You can make it more sophisticated by removing files that have been displayed and files that you skip. -- Piet van Oostrum p...@vanoostrum.org WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] -- http://mail.python.org/mailman/listinfo/python-list
Re: Awsome Python - chained exceptions
On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
On Wed, Feb 13, 2013 at 1:47 PM, Rick Johnson wrote:
On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
If you've ever written an exception handler, you've probably written a
*buggy* exception handler:
def getitem(items, index):
# One-based indexing.
try:
return items[index-1]
except IndexError:
print (Item at index %d is missing % index - 1) # Oops!
Unfortunately, when an exception occurs inside an except or finally
block, the second exception masks the first, and the reason for the
original exception is lost:
py getitem(['one', 'two', 'three'], 5) # Python 2.6
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'
Which (by showing the offensive line) is quite clear to me.
No, the offending (not offensive) line is return items[index-1],
which doesn't feature in your traceback at all.
Do you realize that you are quoting DeAprano and not me? Whether you realize
this fact or not, consider the next two questions.
Q1: How could a line in the try block ever be considered
offensive? Because it throws an error? Are you serious?
Q2: Why would the line in the try block be shown as
a feature of the traceback when the whole intent of
exception handling is to hide the error in the try
block! If you want to raise the exception in the try block
then you place a naked raise statement in the exception
block, BUT THEN, why even wrap the code in a try/except
in the first damn place!?
Man, you and DeAprano must be cut from the same block; or more correctly,
carved by the same shaky hand of a creator suffering the late-stage effects of
Alzheimers disease.
It DOES, however,
feature in the Py3.1 double traceback (it's listed as line 4)..
1. You are using the print function (so we can assume you are using Python
3.x)
He is? Could just as easily be the print statement with a single
argument, with unnecessary parentheses around that argument. Which, if
I recall correctly, is one of the recommended approaches for making
2/3 bi-compatible code.
Really?
Because if he did in-fact write the print statement using parenthesis (in some
foolish attempt to make his code forward-compatible) that would mean i should
add /another/ coding abomination to my earlier list of abominations. The proper
method of using a forward compatible print function is by /importing/ the
feature.
from future import print_function
No. Definitely not. Percent interpolation isn't going anywhere - core
devs have said so - and there are many occasions when it is at least
as well suited to the task as .format() is.
In other words: Screw consistency and to hell with the zen?
Also, it's a notation
that's well understood *across languages* and in a variety of message
interpolation systems. Anyone who's worked with *any* of them will
understand that %s inserts a string, %d a number (in decimal), etc,
Oh yes, because indexing the list of arguments in the format method is SO much
more overhead! Heck, Python=2.7 (read the docs for exact release number) will
allow you to implicitly pass the index:
print {} is one more than {}.format(five, four) # 3.something
...is equivalent to:
print {0} is one more than {1}.format(five, four)
...but what about when you need to substitute the /same/ substring in more than
one location? Using the old nasty interpolation you are foced to write this:
print Chris is a %s who is very %s-ish%('troll', 'troll')
...e yuck! String.format() to the rescue!
print Chris is a {0} who is very {0}-ish.format('troll')
In fact all of these posted examples work in Python=2.7.
So the moral is: You can pass no indexes and the format method will intuit the
indexes from their linear position in the string, or you can pass indexes and
be explicit (plus you can reference a value more than once!), or you can choose
one of the many other great options available of the format method.
http://docs.python.org/2/library/string.html#format-string-syntax
etc. Granted, the exact details after that may change (eg Python has
%r to emit the representation, while Pike uses %O for any object,
with similar notation), but the format specifiers and modifiers that
came from C are fairly stable, readable, and compact.
The fact is that str.format(args) beats the pants off string interpolation
any day and anybody arguing for keeping string interpolation is not thinking
clearly (especially when they first claim consistency between languages and
them expose that claim as a lie) and is also anti-pythonic! To continue to
propagate foolish language designs simply because other people have been
brainwashed by them is, well, foolish. Would you propagate propaganda using the
same excuse?
In
Re: Awsome Python - chained exceptions
On Wednesday, February 13, 2013 10:14:34 AM UTC-6, Rick Johnson wrote: The proper method of using a forward compatible print function is by /importing/ the feature. from future import print_function Urm... of course the proper /PROPER/ way would be to NOT throw an import error! from __future__ import print_function O:-) -- http://mail.python.org/mailman/listinfo/python-list
Re: string.replace doesn't removes :
On Wednesday, February 13, 2013 1:10:14 AM UTC-6, jmfauth wrote:
d = {ord('a'): 'A', ord('b'): '2', ord('c'): 'C'}
'abcdefgabc'.translate(d)
'A2CdefgA2C'
def jmTranslate(s, table):
... table = {ord(k):table[k] for k in table}
... return s.translate(table)
...
d = {'a': 'A', 'b': '2', 'c': 'C'}
jmTranslate('abcdefgabc', d)
'A2CdefgA2C'
d = {'a': None, 'b': None, 'c': None}
jmTranslate('abcdefgabc', d)
'defg'
d = {'a': '€', 'b': '', 'c': ''}
jmTranslate('abcdefgabc', d)
'€defg€'
[quip] I just really prefer a cryptic solution to a problem when a simplistic
and consistent approach would suffice.[/quip] TO HELL WITH THE ZEN!
Beautiful is better than ugly.
BROKEN!
Explicit is better than implicit.
BROKEN!
Simple is better than complex.
BROKEN!
Sparse is better than dense.
BROKEN!
Readability counts.
BROKEN BROKEN BROKEN
Special cases aren't special enough to break the rules.
BROKEN!
In the face of ambiguity, refuse the temptation to guess.
BROKEN!
There should be one-- and preferably only one --obvious way to do it.
BROKEN BROKEN BROKEN!
If the implementation is hard to explain, it's a bad idea.
BROKEN!
If the implementation is easy to explain, it may be a good idea.
REINFORCED BY BAD EXAMPLE
--
http://mail.python.org/mailman/listinfo/python-list
Re: string.replace doesn't removes :
On 13/02/2013 16:34, Rick Johnson wrote:
On Wednesday, February 13, 2013 1:10:14 AM UTC-6, jmfauth wrote:
d = {ord('a'): 'A', ord('b'): '2', ord('c'): 'C'}
'abcdefgabc'.translate(d)
'A2CdefgA2C'
def jmTranslate(s, table):
... table = {ord(k):table[k] for k in table}
... return s.translate(table)
...
d = {'a': 'A', 'b': '2', 'c': 'C'}
jmTranslate('abcdefgabc', d)
'A2CdefgA2C'
d = {'a': None, 'b': None, 'c': None}
jmTranslate('abcdefgabc', d)
'defg'
d = {'a': '€', 'b': '', 'c': ''}
jmTranslate('abcdefgabc', d)
'€defg€'
[quip] I just really prefer a cryptic solution to a problem when a simplistic
and consistent approach would suffice.[/quip] TO HELL WITH THE ZEN!
Beautiful is better than ugly.
BROKEN!
Explicit is better than implicit.
BROKEN!
Simple is better than complex.
BROKEN!
Sparse is better than dense.
BROKEN!
Readability counts.
BROKEN BROKEN BROKEN
Special cases aren't special enough to break the rules.
BROKEN!
In the face of ambiguity, refuse the temptation to guess.
BROKEN!
There should be one-- and preferably only one --obvious way to do it.
BROKEN BROKEN BROKEN!
If the implementation is hard to explain, it's a bad idea.
BROKEN!
If the implementation is easy to explain, it may be a good idea.
REINFORCED BY BAD EXAMPLE
jmf and rr in combination reminded me of this. I hope you all get my
drift :)
http://www.cc.gatech.edu/fac/Spencer.Rugaber/poems/love.txt
--
Cheers.
Mark Lawrence
--
http://mail.python.org/mailman/listinfo/python-list
Re: string.replace doesn't removes :
On Wed, 13 Feb 2013 16:55:36 +, Mark Lawrence wrote:
On 13/02/2013 16:34, Rick Johnson wrote:
On Wednesday, February 13, 2013 1:10:14 AM UTC-6, jmfauth wrote:
d = {ord('a'): 'A', ord('b'): '2', ord('c'): 'C'}
'abcdefgabc'.translate(d)
'A2CdefgA2C'
def jmTranslate(s, table):
... table = {ord(k):table[k] for k in table}
... return s.translate(table)
...
d = {'a': 'A', 'b': '2', 'c': 'C'}
jmTranslate('abcdefgabc', d)
'A2CdefgA2C'
d = {'a': None, 'b': None, 'c': None}
jmTranslate('abcdefgabc', d)
'defg'
d = {'a': '€', 'b': '', 'c': ''}
jmTranslate('abcdefgabc', d)
'€defg€'
[quip] I just really prefer a cryptic solution to a problem when a
simplistic and consistent approach would suffice.[/quip] TO HELL WITH
THE ZEN!
Beautiful is better than ugly.
BROKEN!
Explicit is better than implicit.
BROKEN!
Simple is better than complex.
BROKEN!
Sparse is better than dense.
BROKEN!
Readability counts.
BROKEN BROKEN BROKEN
Special cases aren't special enough to break the rules.
BROKEN!
In the face of ambiguity, refuse the temptation to guess.
BROKEN!
There should be one-- and preferably only one --obvious way to do it.
BROKEN BROKEN BROKEN!
If the implementation is hard to explain, it's a bad idea.
BROKEN!
If the implementation is easy to explain, it may be a good idea.
REINFORCED BY BAD EXAMPLE
jmf and rr in combination reminded me of this. I hope you all get my
drift :)
http://www.cc.gatech.edu/fac/Spencer.Rugaber/poems/love.txt
10-4, good buddy.
--
http://mail.python.org/mailman/listinfo/python-list
Suggested feature: slice syntax within tuples (or even more generally)?
Hello, Would it be feasible to modify the Python grammar to allow ':' to generate slice objects everywhere rather than just indexers and top-level tuples of indexers? Right now in Py2.7, Py3.3: obj[:,2] yields obj[slice(None),2] but obj[(:,1),2] is an error, instead of obj[(slice(None), 1), 2] Also, more generally, you could imagine this working in (almost?) any expression without ambiguity: a = (1:2) could yield a = slice(1,2) See motivating discussion for this at: https://github.com/pydata/pandas/issues/2866 There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that: e = ... yields e = Ellipsis Would there be any downside to changing the handling of ':' as well? It might even make the grammar simpler, in some ways, since indexers won't have to be treated specially. Let me know if you have any thoughts. Thanks! Stephen -- http://mail.python.org/mailman/listinfo/python-list
Simulate Keyboard keypress Delay
I am using the windows api feature getasynckeystate() to check the status of every key pressed; like this; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): #do stuff This works great, almost. The issue that comes up now is that every time i press a key, the code grabs two or three key presses. So i tried making sure that repeated keys weren't pressed repeatedly; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): if oldkeychar == num: #don't do stuff else: #do stuff this works great, but It won't record stuff like 'look' or 'suffer' because it doesn't record repeated keys. So I try doing a delay instead; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): if oldkeychar == num: if crrenttime (time.time() - .5) #do stuff because key has been repeated, but not because it was held down else: #don't do stuff because key is pressed to soon else: #do stuff because key is not repeated currenttime = time.time() this almost works, but I end recording some double keypresses, and missing others. Does anybody have any suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Help understanding import error
I'm using TortoiseHg on Windows, which is implemented in python and includes python (2.7.3) as dlls and a bunch of python modules bunded into a library.zip file. I'm trying to use an extension whose __init__.py does the following import: from distutils.version import LooseVersion and am getting the error message *** failed to import extension reviewboard from C:\Program Files\TortoiseHg\reviewboard: No module named version The thing I don't get is that the library.zip file contains distutils\version.pyo and looking at the text in that it does contain LooseVersion. Also, many other library modules are imported and used without problem, and this extension works fine on my Linux box. Any ideas what could be causing this and how to fix it? thx, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: string.replace doesn't removes :
Rick Johnson於 2013年2月14日星期四UTC+8上午12時34分11秒寫道：
On Wednesday, February 13, 2013 1:10:14 AM UTC-6, jmfauth wrote:
d = {ord('a'): 'A', ord('b'): '2', ord('c'): 'C'}
'abcdefgabc'.translate(d)
'A2CdefgA2C'
def jmTranslate(s, table):
... table = {ord(k):table[k] for k in table}
... return s.translate(table)
...
d = {'a': 'A', 'b': '2', 'c': 'C'}
jmTranslate('abcdefgabc', d)
'A2CdefgA2C'
d = {'a': None, 'b': None, 'c': None}
jmTranslate('abcdefgabc', d)
'defg'
d = {'a': '€', 'b': '', 'c': ''}
jmTranslate('abcdefgabc', d)
'€defg€'
In python the variables of value types, and the variables of lists and
dictionaries are passed to functions somewhat different.
This should be noticed by any serious programmer in python.
--
http://mail.python.org/mailman/listinfo/python-list
I made a small reddit console feed with python last night
If you would like to get a copy of it, instructions are here on Github https://github.com/jawerty/AlienFeed -- http://mail.python.org/mailman/listinfo/python-list
Re: Awsome Python - chained exceptions
On Thu, Feb 14, 2013 at 3:14 AM, Rick Johnson
rantingrickjohn...@gmail.com wrote:
On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
No, the offending (not offensive) line is return items[index-1],
which doesn't feature in your traceback at all.
Do you realize that you are quoting DeAprano and not me? Whether you realize
this fact or not, consider the next two questions.
I knew who I was quoting.
Q1: How could a line in the try block ever be considered
offensive? Because it throws an error? Are you serious?
You're the one who said offensive. I specifically corrected you to
offending, which is the appropriate word in that situation.
Q2: Why would the line in the try block be shown as
a feature of the traceback when the whole intent of
exception handling is to hide the error in the try
block! If you want to raise the exception in the try block
then you place a naked raise statement in the exception
block, BUT THEN, why even wrap the code in a try/except
in the first damn place!?
You seriously need to get into the real world and do some actual
debugging work. Here, let me give you an example of what you might
come across in the real world:
1) The program doesn't exhibit the failure symptoms until it's been
running for a couple of days.
2) Sending the program a SIGHUP influences the symptoms in peculiar ways.
3) The main symptom visible is that something that ought to have 2-3
threads actually has several hundred.
4) Your boss is paranoid about security, so the script files on the
running nodes have all been minified - no comments, no linebreaks,
short variable names, etc.
5) The exact nature of the bug depends on the interactions of up to 12
computers, all running similar code but doing different tasks.
Now tell me, what's the first thing you do? There are many right
answers to this question, but most of them involve one thing: Get more
information. Turn on verbose logging, add a monitoring wrapper, insert
output statements in various places... and make sure your exception
tracebacks give ALL the information.
Man, you and DeAprano must be cut from the same block; or more correctly,
carved by the same shaky hand of a creator suffering the late-stage effects
of Alzheimers disease.
D'Aprano (note, that's a 39 not a 101) and I both happen to have some
real-world experience. A bit of a rough teacher, and the tuition fees
are ridiculously high, but you learn things that aren't taught
anywhere else.
He is? Could just as easily be the print statement with a single
argument, with unnecessary parentheses around that argument. Which, if
I recall correctly, is one of the recommended approaches for making
2/3 bi-compatible code.
Really?
Because if he did in-fact write the print statement using parenthesis (in
some foolish attempt to make his code forward-compatible) that would mean i
should add /another/ coding abomination to my earlier list of abominations.
The proper method of using a forward compatible print function is by
/importing/ the feature.
from future import print_function
import __future__
__future__.print_function
_Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 65536)
Which works back as far as 2.6 but that's all. Simply putting parens
around the argument works all the way back to... hmm. Further back
than I've ever had to support, but then, I only started using Python
seriously a few years ago. Steven?
No. Definitely not. Percent interpolation isn't going anywhere - core
devs have said so - and there are many occasions when it is at least
as well suited to the task as .format() is.
In other words: Screw consistency and to hell with the zen?
Percent interpolation is plenty obvious, it's simple, it's clean, and
you're welcome to hate it if you like. Doesn't bother me.
...but what about when you need to substitute the /same/ substring in more
than one location? Using the old nasty interpolation you are foced to write
this:
print Chris is a %s who is very %s-ish%('troll', 'troll')
...e yuck! String.format() to the rescue!
print Chris is a {0} who is very {0}-ish.format('troll')
Yeah, in Pike I'd just use %s to reuse the argument, or %[0]s to
explicitly set the index. If Python didn't have .format() and the
percent-haters like you, those features could easily be implemented.
If all you're doing is concatenating five strings, three of them
constants, there are plenty of other ways to do it; are you going to
start hating on str.format because you could use concatenation or
str.join()? Which is the one obvious way to do it?
So let's look at a more useful example. You need to tabulate some
data. For each line of output, you have a descriptive string, a
number, and a floating point value, and you want to output them like
this:
Normal 73 105.23
Disconnected 32 14.00
Shutting down 0 0.00
Busy 31333.33
Overloaded11942.07
First attempt at a Python prog (Chess)
New to Python, which I really like BTW.
First serious prog. Hope you like it. I know it needs a 'can't move if
your King would be put into check' test. But the weighted value of the
King piece does a surprising emergent job.
#!/usr/bin/python -tt
# -*- coding: utf-8 -*-
# Copyright (C) 2013 Chris Hinsley, GPL V3 License
import sys
import random
import os
PLY = 3
EMPTY = 0
BLACK = 1
WHITE = 2
NO_CAPTURE = 3
MAY_CAPTURE = 4
MUST_CAPTURE = 5
def piece_type(piece):
return EMPTY if piece == 32 else BLACK if chr(piece) in 'KQRBNP' else WHITE
def display_board(board):
print ' a b c d e f g h'
print '+---+---+---+---+---+---+---+---+'
for row in range(8):
for col in range(8):
sys.stdout.write('| ')
sys.stdout.write(chr(board[row * 8 + col]))
sys.stdout.write(' ')
sys.stdout.write('|')
print 8 - row
print '+---+---+---+---+---+---+---+---+'
def piece_moves(board, index, dx, dy, capture_flag, distance):
piece = board[index]
type = piece_type(piece)
cx = index % 8
cy = index / 8
for step in range(distance):
nx = cx + (dx * (step + 1))
ny = cy + (dy * (step + 1))
if nx in range(8) and ny in range(8):
newindex = ny * 8 + nx
newpiece = board[newindex]
newtype = piece_type(newpiece)
if capture_flag == MUST_CAPTURE:
if newtype != EMPTY and newtype != type:
board[index] = ' '
if (ny == 0 or ny == 7) and chr(piece) in 'Pp':
for promote in 'QRBN' if type == BLACK else 'qrbn':
board[newindex] = promote
yield board
else:
board[newindex] = piece
yield board
board[index], board[newindex] = piece, newpiece
elif capture_flag == MAY_CAPTURE:
if newtype == EMPTY or newtype != type:
board[index], board[newindex] = ' ', piece
yield board
board[index], board[newindex] = piece, newpiece
break
elif newtype == EMPTY:
board[index] = ' '
if (ny == 0 or ny == 7) and chr(piece) in 'Pp':
for promote in 'QRBN' if type == BLACK else 'qrbn':
board[newindex] = promote
yield board
else:
board[newindex] = piece
yield board
board[index], board[newindex] = piece, newpiece
else:
break
def pawn_moves(board, index, options):
for x, y, flag, distance in options:
for new_board in piece_moves(board, index, x, y, flag, distance):
yield new_board
def other_moves(board, index, options, distance):
for x, y in options:
for new_board in piece_moves(board, index, x, y, MAY_CAPTURE,
distance):
yield new_board
def black_pawn_moves(board, index):
distance = 2 if index in range(8, 16) else 1
for new_board in pawn_moves(board, index, [(0, 1, NO_CAPTURE,
distance), (-1, 1, MUST_CAPTURE, 1), (1, 1, MUST_CAPTURE, 1)]):
yield new_board
def white_pawn_moves(board, index):
distance = 2 if index in range(48, 56) else 1
for new_board in pawn_moves(board, index, [(0, -1, NO_CAPTURE,
distance), (-1, -1, MUST_CAPTURE, 1), (1, -1, MUST_CAPTURE, 1)]):
yield new_board
def rook_moves(board, index):
for new_board in other_moves(board, index, [(0, -1), (-1, 0), (0,
1), (1, 0)], 7):
yield new_board
def bishop_moves(board, index):
for new_board in other_moves(board, index, [(-1, -1), (-1, 1), (1,
1), (1, -1)], 7):
yield new_board
def knight_moves(board, index):
for new_board in other_moves(board, index, [(-2, 1), (2, -1), (2,
1), (-1, -2), (-1, 2), (1, -2), (1, 2)], 1):
yield new_board
def queen_moves(board, index):
for new_board in bishop_moves(board, index):
yield new_board
for new_board in rook_moves(board, index):
yield new_board
def king_moves(board, index):
for new_board in other_moves(board, index, [(0, -1), (-1, 0), (0,
1), (1, 0), (-1, -1), (-1, 1), (1, 1), (1, -1)], 1):
yield new_board
moves = {'P' : black_pawn_moves, 'p' : white_pawn_moves, \
'R' : rook_moves, 'r' : rook_moves, \
'B' : bishop_moves, 'b' : bishop_moves, \
'N' : knight_moves, 'n' : knight_moves, \
'Q' : queen_moves, 'q' : queen_moves, \
'K' : king_moves, 'k' : king_moves}
def all_moves(board, turn):
for index, piece in enumerate(board):
if piece_type(piece) == turn:
for new_board in moves[chr(piece)](board, index):
yield new_board
piece_values = {'K' : (100, 0), 'k' : (0, 100), \
'P' : (1, 0), 'p' : (0, 1), \
'N' : (3, 0), 'n' : (0, 3), \
'B' : (3, 0), 'b' : (0, 3), \
Re: First attempt at a Python prog (Chess)
On 13 February 2013 23:25, Chris Hinsley chris.hins...@gmail.com wrote: New to Python, which I really like BTW. Glad to hear it. First serious prog. Hope you like it. I know it needs a 'can't move if your King would be put into check' test. But the weighted value of the King piece does a surprising emergent job. [SNIP program] Your program looks good. Were you looking for feedback (I'm sure someone would give some if so)? Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: I made a small reddit console feed with python last night
On 02/13/2013 04:40 PM, Jared Wright wrote: If you would like to get a copy of it, instructions are here on Github https://github.com/jawerty/AlienFeed What's a reddit console feed? -- http://mail.python.org/mailman/listinfo/python-list
Re: Simulate Keyboard keypress Delay
DaGeek247於 2013年2月14日星期四UTC+8上午3時47分36秒寫道： I am using the windows api feature getasynckeystate() to check the status of every key pressed; like this; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): #do stuff This works great, almost. The issue that comes up now is that every time i press a key, the code grabs two or three key presses. So i tried making sure that repeated keys weren't pressed repeatedly; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): if oldkeychar == num: #don't do stuff else: #do stuff this works great, but It won't record stuff like 'look' or 'suffer' because it doesn't record repeated keys. So I try doing a delay instead; #always checking while(True): #iterate through list of ascii codes for num in range(0,127): #if ascii code key is being pressed if win32api.GetAsyncKeyState(num): if oldkeychar == num: if crrenttime (time.time() - .5) #do stuff because key has been repeated, but not because it was held down else: #don't do stuff because key is pressed to soon else: #do stuff because key is not repeated currenttime = time.time() this almost works, but I end recording some double keypresses, and missing others. Does anybody have any suggestions? I believe you can use the raw_input function in python. But loop through strings ended by \r\n or \r. -- http://mail.python.org/mailman/listinfo/python-list
Re: First attempt at a Python prog (Chess)
On 2013-02-13 23:55:20 +, Oscar Benjamin said: On 13 February 2013 23:25, Chris Hinsley chris.hins...@gmail.com wrote: New to Python, which I really like BTW. Glad to hear it. First serious prog. Hope you like it. I know it needs a 'can't move if your King would be put into check' test. But the weighted value of the King piece does a surprising emergent job. [SNIP program] Your program looks good. Were you looking for feedback (I'm sure someone would give some if so)? Oscar I suppose so yes. I was just 'putting it out there' to see if it was interesting/useful to anyone. No doubt there are many Python features I could use to improve on this. First thing that occurred to me on deciding to try Python was the idea of Generator functions to enumerate all the possible moves of a Chess game, and that 'yield' would make the prog relatively compact. I wish Shedskin could cope with them ! PyPy runs it OK. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Statistics...help with numpy/scipy install
I am sure I have python installed. I have been running it. in command line the window title is c:\python33\python.exe. The first line begins Python 3.3.0. Later in the line is the string 64 bit AMD64] on Win32. Thus it appears I am trying to run a 32bit numpy with a 64bit python. (Seems like a big ole 64 bit python should be able to swallow a little 32 bitty numpy). Is there a 64bit numpy? If not why not? Can someone get on this? Seriously, I'm under the impression that I need the 64 bit python because I have a 64 bit OS. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Makefiles... are they possible?
Roy Smith wrote: In article 511b2a7c$0$11096$c3e8...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 12 Feb 2013 20:06:35 -0500, Roy Smith wrote: One thing we do in our Makefiles is find . -name '*.pyc' | xargs rm. It avoids all sorts of nasty and hard to track down bugs (consider what happens if you move a .py file from one place in your source tree to another and leave the old .pyc behind). How often do you move files around in the source tree? It has happened enough times to make us look for a solution. Which means more than once. Maybe the solution is education, not a technical fix. I've suspicious of technical fixes for developer problems, because in my experience that strategy ends in a race to the bottom where you end up with coding standards and procedures that assume everyone is a code monkey who can barely spell PC. It doesn't protect the monkeys, because there is no end to the ways they can screw up, while the competent developers suffer under repressive, BD procedures that hinder more than help. YMMV. I prefer to keep the .pyc files, and only remove them when necessary, rather than to remove them whether it's necessary or not. It's not just because I'm an arrogant SOB who expects my team of developers to know at least more than me, therefore if I know enough to look for orphaned .pyc files so should they. It's because I am a big believer that your development system should be as close as possible to the eventual deployment system as is practical. Your app will (probably) use .pyc files when it is deployed, so you should do the same when developing. Otherwise you can get bugs in deployment that you cannot reproduce in development because the environments are different. Meanwhile, *every* time you run make, you take a performance hit on every Python module in your project, whether it has moved or not. The performance hit is minimal. I guess that depends on the size of your project and how much you care about the start up time. But as general advice, no, it may not be minimal. [...] Another solution would be if there was a flag you could give to Python to tell it, Only import a .pyc if the corresponding .py file exists. It's already checking to see if the .py is newer, so this wouldn't even cost anything. That's called Python 3.3 :-) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Makefiles... are they possible?
In article 511c501d$0$6512$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I prefer to keep the .pyc files, and only remove them when necessary, rather than to remove them whether it's necessary or not. It's not just because I'm an arrogant SOB who expects my team of developers to know at least more than me, therefore if I know enough to look for orphaned .pyc files so should they. It's because I am a big believer that your development system should be as close as possible to the eventual deployment system as is practical. Your app will (probably) use .pyc files when it is deployed, so you should do the same when developing. Heh. Our deployment system rolls out all the source code from scratch on every deploy. Meanwhile, *every* time you run make, you take a performance hit on every Python module in your project, whether it has moved or not. Yup. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
On 2/13/2013 2:00 PM, stephenw...@gmail.com wrote: Hello, Would it be feasible to modify the Python grammar to allow ':' to generate slice objects everywhere rather than just indexers and top-level tuples of indexers? Right now in Py2.7, Py3.3: obj[:,2] yields obj[slice(None),2] but obj[(:,1),2] is an error, instead of obj[(slice(None), 1), 2] Also, more generally, you could imagine this working in (almost?) any expression without ambiguity: a = (1:2) could yield a = slice(1,2) I believe the idea of slice literals has been rejected. See motivating discussion for this at: https://github.com/pydata/pandas/issues/2866 There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that: e = ... yields e = Ellipsis One dubious move does not justify another. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Statistics...help with numpy/scipy install
On 2/13/2013 9:38 PM, Rex Macey wrote: I am sure I have python installed. I have been running it. in command line the window title is c:\python33\python.exe. The first line begins Python 3.3.0. Later in the line is the string 64 bit AMD64] on Win32. Thus it appears I am trying to run a 32bit numpy with a 64bit python. (Seems like a big ole 64 bit python should be able to swallow a little 32 bitty numpy). Is there a 64bit numpy? If not why not? Ask the numpy people. I am surprised since a reason to be using 64 rather than 32 bit python is to have objects larger than 2 gigabytes and memory larger than 4 gigabytes. Numerical/scientific programming is relatively likely to need such. someone get on this? Seriously, I'm under the impression that I need the 64 bit python because I have a 64 bit OS. If you look on your C: drive, you should have both 'Program Files' and 'Program Files (x86)' directories. The latter is for 32 bit programs. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
I believe the idea of slice literals has been rejected. That's too bad...do you have a link to prior discussion on this and what the reasoning was for rejection? There doesn't seem to be any particular downside and things would be more consistent with slice syntax allowed anywhere. It would be helpful in other cases as well other than the one linked to, since there's good reason to be able to succinctly create and reuse the same indexer object multiple times without having to convert everything into slice() calls. -Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: First attempt at a Python prog (Chess)
Chris Hinsley chris.hins...@gmail.com wrote: New to Python, which I really like BTW. First serious prog. Hope you like it. I know it needs a 'can't move if your King would be put into check' test. But the weighted value of the King piece does a surprising emergent job. It looks a little like a C program ported line-by-line to Python. For example, in Python, there's no reason not to keep the board as an 8x8 array instead of a 64-element list. That by itself would make the code easier to read. It would also let you replace this: for row in range(8): for col in range(8): with the more Pythonic: for row in board: for cell in row: I would probably replace the piece_type function with a map that maps the piece number directly to the piece -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
Apparently Travis Oliphant of numpy would like this as well... http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html On Wednesday, February 13, 2013 2:00:15 PM UTC-5, steph...@gmail.com wrote: Hello, Would it be feasible to modify the Python grammar to allow ':' to generate slice objects everywhere rather than just indexers and top-level tuples of indexers? Right now in Py2.7, Py3.3: obj[:,2] yields obj[slice(None),2] but obj[(:,1),2] is an error, instead of obj[(slice(None), 1), 2] Also, more generally, you could imagine this working in (almost?) any expression without ambiguity: a = (1:2) could yield a = slice(1,2) See motivating discussion for this at: https://github.com/pydata/pandas/issues/2866 There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that: e = ... yields e = Ellipsis Would there be any downside to changing the handling of ':' as well? It might even make the grammar simpler, in some ways, since indexers won't have to be treated specially. Let me know if you have any thoughts. Thanks! Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Awsome Python - chained exceptions
On Thu, 14 Feb 2013 09:10:42 +1100, Chris Angelico wrote: Quoting Rick Johnson: Q2: Why would the line in the try block be shown as a feature of the traceback when the whole intent of exception handling is to hide the error in the try block! If you want to raise the exception in the try block then you place a naked raise statement in the exception block, BUT THEN, why even wrap the code in a try/except in the first damn place!? Here is one example of using raise to re-raise an exception you have just caught: import errno paths = [here, there, somewhere else] for location in paths: filename = os.path.join(location, prefs.ini) try: f = open(filename) except IOError as e: if e.errno != errno.ENOENT: # File not found. raise You seriously need to get into the real world and do some actual debugging work. Amen to that brother. What is it that they say? Those who can, do. Those who can't, teach. Those who can't teach, write rants on the Internet criticising others. [...] He is? Could just as easily be the print statement with a single argument, with unnecessary parentheses around that argument. Which, if I recall correctly, is one of the recommended approaches for making 2/3 bi-compatible code. Really? Because if he did in-fact write the print statement using parenthesis (in some foolish attempt to make his code forward-compatible) that would mean i should add /another/ coding abomination to my earlier list of abominations. The proper method of using a forward compatible print function is by /importing/ the feature. from future import print_function import __future__ __future__.print_function _Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 65536) Which works back as far as 2.6 but that's all. Simply putting parens around the argument works all the way back to... hmm. Further back than I've ever had to support, but then, I only started using Python seriously a few years ago. Steven? Putting parens around the argument to print works going back to at least Python 0.9.1, which is before Python had delimiters: steve@runes:~$ ./python0.9.1 s = string Parsing error: file stdin, line 1: s = string ^ Unhandled exception: run-time error: syntax error s = 'string' print s string print (s) string You can always wrap any expression with an extra pair of round brackets. Of course, the correct way of doing this is with from __future__ import print_function, but really, who cares? It's just a trivial example. If the worst criticism someone can make of my example is that I took a short- cut when printing, I can live with that. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Makefiles... are they possible?
On Thu, Feb 14, 2013 at 1:46 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I prefer to keep the .pyc files, and only remove them when necessary, rather than to remove them whether it's necessary or not. Solution to that could be just to have your makefile wipe out orphanned pyc files, rather than all of them. Still might be a performance hit (if it has to wade through piles of pyc/py files to see which ones aren't needed), but otherwise should be safe. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Awsome Python - chained exceptions
On Tue, Feb 12, 2013 at 8:01 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: On Tuesday, February 12, 2013 12:01:45 PM UTC-6, Zero Piraeus wrote: You could call them PyW00ts. +1 on the name -INFINITY on the execution Actually i am happy that DeAprano used the unintuitive tag now. Bad enough to use an unintuitive tag. Worse to misspell it. But it would been a crime to tarnish such an intuitive tag as PyW00ts with the clumsy teachings provided. 1. Subject lines are not tags. If you want to categorize the post with a tag for later reference, then by all means do so; any halfway decent reader will let you do this. It's not up to the post author to tag posts for you. 2. If you're going to criticize someone for their spelling, at least be sure to spell correctly the name of the person you are addressing. You've consistently misspelled Steven's surname in several posts that I've noticed. -- http://mail.python.org/mailman/listinfo/python-list
Exception ... in generator object ... ignored Messages
Hi, Running the unit tests for some generator code, prints, as a side effect, numerous messages of the form: ... Exception NameError: global name 'l' is not defined in generator object _dagpype_internal_fn_act at 0x9d4c500 ignored Exception AttributeError: 'NoneType' object has no attribute 'close' in generator object split at 0x7601640 ignored Exception AttributeError: 'NoneType' object has no attribute 'close' in generator object split at 0x7601690 ignored ... The tests otherwise run fine. Is there any way to catch the point where such a message originates, and print a traceback? I find it difficult to debug otherwise. I've tried running Python with -W error, catching warnings with context managers, and so forth, but without any success. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
On Wed, 13 Feb 2013 21:54:43 -0800, stephenwlin wrote: I believe the idea of slice literals has been rejected. That's too bad...do you have a link to prior discussion on this and what the reasoning was for rejection? There doesn't seem to be any particular downside and things would be more consistent with slice syntax allowed anywhere. There's *always* downside to new syntax. The question is, does the benefit exceed the downside? - new syntax requires more complexity in the parser; - new tests for it; - more documentation; - increase in the number of things people have to learn before they can read and write Python code; - takes the language further away from executable pseudo-code and closer to line noise; - somebody has to actually write the code, write the tests, write the documentation; and somebody else has to review it; for a chronically short-handed dev team where there are hundreds of bugs and feature requests in the queue, this is a significant cost. Now, you might argue that these are all *low* cost, but they're not zero, and how do they stack up against the benefits? What are the benefits of syntactic sugar for slice objects? Personally, there's not much difference to my eye between: S = slice S(1, 20, 3) versus (1:20:3) so I'm skeptical that the benefit is much greater than the cost, as low as that cost may be. It would be helpful in other cases as well other than the one linked to, since there's good reason to be able to succinctly create and reuse the same indexer object multiple times without having to convert everything into slice() calls. I don't quite understand this argument. If you mean that you can do this: s = (1:2) # Like slice(1, 2). print alist[s] print blist[s] # reuse the slice object print clist[s] you can replace the line s = (1:2) to a call to slice, and still reuse the slice object. So I don't understand what the syntactic sugar gains you. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
[issue17170] string method lookup is too slow
Larry Hastings added the comment: Argument Clinic has languished for lack of time. I didn't get much feedback, though a couple people were shouting for a PEP, which I was resisting. I figured, if they have something to say, they can go ahead and reply on the tracker issue, and if they don't have something to say, why do we need a PEP? I need to reply to one bit of thorough feedback, and after that--I don't know. I'd like to get things moving before PyCon so we can point sprinters at it. -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Senthil Kumaran added the comment: The doc change looks good to me. I am adding Terry and Ezio to see if they have any comments on wordings in the doc. If not, I can commit this change. I think that this is helpful. -- nosy: +ezio.melotti, orsenthil, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Chris Jerdonek added the comment: I commented above that the tests are not very DRY though. Shouldn't there be tests to check that the documented behavior is correct? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Senthil Kumaran added the comment: Chris: The patch is for the docs. the test code I believe, is for reference. It would be to run it on different OS and verify the documentation matches the behavior.I am okay with more than one person verifying this and I shall do on OS'es I have. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17170] string method lookup is too slow
Larry Hastings added the comment: Oh, and, as to whether Argument Clinic would solve this problem, the answer is not yet. Right now Argument Clinic literally generates calls to PyArg_ParseTupleAndKeywords. (In special cases it switches to PyArg_ParseTuple.) I'm more interested in Argument Clinic from the API perspective; I wanted to make a better way of specifying arguments to functions so we got all the metadata we needed without having to endlessly repeat ourselves. Truthfully I was hoping someone else would pick up the gauntlet once it was checked in and make a new argument processing API / hack up the Argument Clinic output to make it faster. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17170] string method lookup is too slow
Antoine Pitrou added the comment: Truthfully I was hoping someone else would pick up the gauntlet once it was checked in and make a new argument processing API / hack up the Argument Clinic output to make it faster. Argument Clinic's preprocessing would be a very nice building block to generate faster parsing sequences. Like Nick I'd still like to see a PEP, though ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17197] c/profile refactoring
Antoine Pitrou added the comment: The patch doesn't look right to me. If you import cProfile, profile will always invoke the cProfile profiler. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
Antoine Pitrou added the comment: Would there be a way to automatically switch the flag as necessary? (i.e. when writing more than 2GB, I guess) -- nosy: +hynek, pitrou, tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17197] c/profile refactoring
Giampaolo Rodola' added the comment: No, it's the other way around. It's from cProfile which I import profile. diff --git a/Lib/cProfile.py b/Lib/cProfile.py --- a/Lib/cProfile.py +++ b/Lib/cProfile.py ... +import profile as _pyprofile -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +christian.heimes, hynek, tarek priority: normal - high type: - security versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5308] cannot marshal objects with more than 2**31 elements
Roundup Robot added the comment: New changeset 385d982ce641 by Serhiy Storchaka in branch '2.7': Issue #5308: Raise ValueError when marshalling too large object (a sequence http://hg.python.org/cpython/rev/385d982ce641 New changeset e0464fa28c85 by Serhiy Storchaka in branch '3.2': Issue #5308: Raise ValueError when marshalling too large object (a sequence http://hg.python.org/cpython/rev/e0464fa28c85 New changeset b48e1cd2d3be by Serhiy Storchaka in branch '3.3': Issue #5308: Raise ValueError when marshalling too large object (a sequence http://hg.python.org/cpython/rev/b48e1cd2d3be New changeset ea36478a36ee by Serhiy Storchaka in branch 'default': Issue #5308: Raise ValueError when marshalling too large object (a sequence http://hg.python.org/cpython/rev/ea36478a36ee -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16996] Reuse shutil.which() in webbrowser module
Roundup Robot added the comment: New changeset 050c94f5f72c by Serhiy Storchaka in branch 'default': Issue #16996: webbrowser module now uses shutil.which() to find a http://hg.python.org/cpython/rev/050c94f5f72c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16996 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11311] StringIO.readline(0) returns incorrect results
Roundup Robot added the comment: New changeset 7513bd184a01 by Serhiy Storchaka in branch '2.7': Issue #11311: StringIO.readline(0) now returns an empty string as all other http://hg.python.org/cpython/rev/7513bd184a01 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5308] cannot marshal objects with more than 2**31 elements
Roundup Robot added the comment: New changeset 72e75ea25d00 by Serhiy Storchaka in branch '2.7': Fix tests for issue #5308. http://hg.python.org/cpython/rev/72e75ea25d00 New changeset 0407e5e5915e by Serhiy Storchaka in branch '3.3': Cleanup a test for issue #5308. http://hg.python.org/cpython/rev/0407e5e5915e New changeset e45f2fcf202c by Serhiy Storchaka in branch 'default': Cleanup a test for issue #5308. http://hg.python.org/cpython/rev/e45f2fcf202c -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5308] cannot marshal objects with more than 2**31 elements
Serhiy Storchaka added the comment: Perhaps you could add a bigmem test for this? (assuming you have enough memory somewhere to test it) Some tests require more than 252 GiB of memory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11311] StringIO.readline(0) returns incorrect results
Serhiy Storchaka added the comment: Fixed. Thank you for the report, Ville. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16996] Reuse shutil.which() in webbrowser module
Serhiy Storchaka added the comment: Thank you, Senthil. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16996 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16692] Support TLS 1.1 and TLS 1.2
Changes by Michele Orrù maker...@gmail.com: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16692 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
Serhiy Storchaka added the comment: Would there be a way to automatically switch the flag as necessary? (i.e. when writing more than 2GB, I guess) Yes, there is a special flag for this in zipfile. It is named allowZip64. The only reason to use allowZip64=False is when you expect to unzip a zipfile with a tool which doesn't support zip64 (PKUNZIP.EXE for DOS?) and you want to keep yourself from unintentional zipping a file larger than 2 GiB. Perhaps sometime we should to change the default value for allowZip64 from False to True. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16996] Reuse shutil.which() in webbrowser module
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16996 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17193] Use binary prefixes
Serhiy Storchaka added the comment: For what versions can I apply this patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: Thanks for the report. I agree with your analysis. We should follow the behavior of cp and always strip off the suid/sgid bits in shutil.copy(). coreutil's cp removes the bits and doesn't handle source owner = destination owner special. There are other bits that may need special treatment, too. I'm going to check the sources of cp. -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: cp removes three bits unless preserve ownership is enabled and some additional things are true. mode = ~ (S_ISUID | S_ISGID | S_ISVTX) S_ISVTX is the sticky bit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Hynek Schlawack added the comment: While I agree that it’s a problem, I’m a bit uneasy about changing that back to 2.7. I’m pretty sure this would break numerous programs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: Here is a patch for the issue with test and doc updates. I'm escalating the bug to release blocker to draw the attention of our RMs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Changes by Christian Heimes li...@cheimes.de: -- keywords: +patch Added file: http://bugs.python.org/file29057/17180.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime
Changes by R. David Murray rdmur...@bitdance.com: -- type: enhancement - behavior versions: +Python 3.2, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: Sorry for the extra noise. I got into a comment conflict with Hynek. Hynek, I don't think it's going to break lots of apps. setuid/setgid programs are rare these days. Most operating system ignore sticky bits on files, too. It may break system scripts that copy entire Unix systems with a recursive copytree(), though ... -- nosy: +benjamin.peterson, georg.brandl, larry priority: high - release blocker stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Hynek Schlawack added the comment: Yeah, I’m thinking about backup scripts etc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17197] c/profile refactoring
Antoine Pitrou added the comment: No, it's the other way around. It's from cProfile which I import profile. diff --git a/Lib/cProfile.py b/Lib/cProfile.py --- a/Lib/cProfile.py +++ b/Lib/cProfile.py ... +import profile as _pyprofile That's exactly what I'm saying. Once you import cProfile, the attributes on the profile functions are overriden. Either way, a module shouldn't mutate another module's functions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17197 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
Antoine Pitrou added the comment: Yes, there is a special flag for this in zipfile. It is named allowZip64. Then I think shutil should set allowZip64 to True by default. People who want fine-grained control over the zipfile's characteristics can still use the zipfile module directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16743] mmap on Windows can mishandle files larger than sys.maxsize
Roundup Robot added the comment: New changeset b1bbe519770b by Richard Oudkerk in branch '2.7': Issue #16743: Fix mmap overflow check on 32 bit Windows http://hg.python.org/cpython/rev/b1bbe519770b New changeset c2c84d3ab393 by Richard Oudkerk in branch '3.2': Issue #16743: Fix mmap overflow check on 32 bit Windows http://hg.python.org/cpython/rev/c2c84d3ab393 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: Here is a new patch with a new keyword argument preserve_sbits. Perhaps we use `True` as default for Python 2.6 to 3.3 and switch to False in Python 3.4? -- Added file: http://bugs.python.org/file29058/17180_preserve_sbits.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16612] Integrate Argument Clinic specialized preprocessor into CPython trunk
Stefan Krah added the comment: Here's a proposal for an alternative without parameter docstrings and a different DSL (see os_stat.c). I guess it's easiest to present my thoughts in list form. Changes and rationale: == Split docstring into function header and rest - - Since the docstrings aren't repeated, less vertical space is used. - The main part of the docstring can go into a header file. - It's (IMO) easier to compare the generated header (see OS_STAT_HEADER) to the specification in the comment. More formal DSL --- This is my personal opinion: The existing DSL is fine for a configuration file (think .hgrc), but I have trouble with it in the context of a C file. Most importantly, I'm unable to take in the required information at a single glance. So I propose to make the structure of the specification explicit. For me the result is more readable. Also, it's already pretty close to a formal grammar and can be optionally condensed into single lines. Logical grouping The preprocessor comment, OS_STAT_HEADER and the os_stat() definition are close together and fit on a single screen. -- Added file: http://bugs.python.org/file29059/os_stat.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Hynek Schlawack added the comment: SGTM. I’d like an explicit warning on the security implications in the docs though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
Serhiy Storchaka added the comment: Agree. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16743] mmap on Windows can mishandle files larger than sys.maxsize
Serhiy Storchaka added the comment: Perhaps NEWS item needed for this change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17089] Expat parser parses strings only when XML encoding is UTF-8
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17089 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17061] tokenize unconditionally emits NL after comment lines blank lines
Thomas Kluyver added the comment: Hmm, that's interesting. For our purposes, a blank line or a comment line shouldn't result in a continuation prompt. This is consistent with what the plain Python shell does. As part of this, we're tokenizing the code, and if the final \n results in a NL token (instead of NEWLINE), we wait to build a 'Python line'. (Likewise if the final \n doesn't appear before EOFError, indicating that a string continues to the next line). Since tokenize doesn't expose parenlev (parentheses level), my modification to tokenize makes this work as we need. Maybe another way forward would be to make parenlev accessible in some way, so that we can use that rather than using NL == parenlev 0? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime
Vinay Sajip added the comment:
It's not a bug - the reason it's like that is that it allows conversion and
format specifiers to be given - {field_name!conversion:format_spec}.
Of course a more robust solution using regular expressions could be
implemented, but it's not really worth it. If there's a misspelt field name,
generally you'll know because there will either be an exception raised, or (in
production) no output will be produced.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17199
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime
Enrique A Tobis added the comment: Thanks! Got it. Sorry for the noise. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17199] Slightly wrong behavior of logging.StrFormatStyle.usesTime
R. David Murray added the comment: I would still consider it a bug myself, but I understand and accept that you feel it is not worth fixing. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17170] string method lookup is too slow
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16743] mmap on Windows can mishandle files larger than sys.maxsize
Roundup Robot added the comment: New changeset 82db097cd2e0 by Richard Oudkerk in branch '2.7': Add Misc/NEWS entry for Issue #16743 http://hg.python.org/cpython/rev/82db097cd2e0 New changeset efe489f87881 by Richard Oudkerk in branch '3.2': Add Misc/NEWS entry for Issue #16743 http://hg.python.org/cpython/rev/efe489f87881 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16743] mmap on Windows can mishandle files larger than sys.maxsize
Richard Oudkerk added the comment: Perhaps NEWS item needed for this change. Done. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16743 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7279] decimal.py: == and != comparisons involving NaNs
Sebastian Berg added the comment:
This is closed, and maybe I am missing something. But from a general point of
view, why does hashing of NaN not raise an error as it did for decimals, i.e.
why was this not resolved exactly the other way around? I am mostly just
wondering about this it is not a problem for me.
Hashing NaNs seems dangerous and surprising because it might work in
dicts/sets, but normally doesn't. (The only thing for it to work right would be
if NaN was a singleton, but that is impossible for subclasses, etc.).
The thing is:
In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3}
In [17]: s
Out[17]: {nan: 1, nan: 2, nan: 3}
In [18]: s[float('nan')]
KeyError: nan
In [19]: n = float('nan')
In [20]: s = {n: 1, n: 2, n: 3}
In [21]: s
Out[21]: {nan: 3}
This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b`
then `a == b` which is simply wrong for NaNs and also makes comparisons of
iterables including NaNs an impossible business. NaNs have their unavoidable
weirdness, but at least for dictionaries/sets it would seem more clear to me if
they raised an error.
--
nosy: +seberg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7279
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Todd Rovito added the comment: Chris, I first verified the issue then created some wording and you pointed out that we needed test cases so I created a bunch of test cases. As you pointed out I count 2*3*2=12 possibilities to check (excluding src and dst being on different filesystems): so I created 16 test cases then discovered that the behavior is different on Windows and Unix so all together there are 32 test cases. Your last comment about the test cases being Dry didn't make sense to me. If you provide specific feedback I would be glad to work on the issue. The test cases are designed to make sure that the documented behavior is actually how Python performs. It made the most sense to me to put together two patches one for the test cases and another for the documentation, but maybe that has confused everybody? If it would help I could submit a single patch. OSRenameCombinations.py was just for reference to prove to myself that I got all the possible test cases. I am a fairly new Python contributor and this is my first attempt at writing test cases so I could be missing something. Thanks for the mentorship and the time required for a little extra guidance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17193] Use binary prefixes
Brett Cannon added the comment: IMO I say just do 3.4 since it isn't really a bug fix but a cleanup, but I wouldn't object if it was backported. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
William Mallard added the comment: Ok, here's a patch that makes zip64 the default in make_archive() when format='zip'. I also agree that ZipFile should set allowZip64=True by default. (PKZIP has supported zip64 since 2001!) -- Added file: http://bugs.python.org/file29060/shutil_zip64_by_default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7279] decimal.py: == and != comparisons involving NaNs
Mark Dickinson added the comment: Sebastian: I think this discussion is a bit off-topic for this particular bug; you might want to raise it on python-dev or python-ideas instead. Bear in mind, though, that the behaviour of NaNs and containers has been discussed to death many times in the past; I'd suggest not bringing the issue up again unless there's something genuinely new to bring to the discussion. The current behaviour is certainly a compromise, but it seems to be the best compromise available. Note that with respect to this particular issue: it's only *signalling* nans that raise on hashing for the Decimal type. Quiet nans are hashable as usual. Since for float, all nans can be regarded as quiet, Decimal and float behave the same way on this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7279] decimal.py: == and != comparisons involving NaNs
Sebastian Berg added the comment: Thanks, yes, you are right, should have googled a bit more anyway. Though I did not find much on the hashable vs unhashable itself, so if I ever stumble across it again, I will write a mail... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16612] Integrate Argument Clinic specialized preprocessor into CPython trunk
Antoine Pitrou added the comment: Here's a proposal for an alternative without parameter docstrings and a different DSL (see os_stat.c). I guess it's easiest to present my thoughts in list form. It's a bit difficult to give an opinion without a more formal definition. For example it seems you are using REQUIRED and KEYWORD as opposites, but a required argument can also be a keyword argument. As for the docstring: I would like it better if I could avoid typing the cumbersome \n\s. As for the general parameter declaration syntax: I think it shouldn't be too verbose, otherwise it will quickly become tiring. (also I don't think it should be required to write [preprocessor] twice) -- title: Integrate Argument Clinic specialized preprocessor into CPython trunk - Integrate Argument Clinic specialized preprocessor into CPython trunk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17192] libffi-3.0.12 import
Arfrever Frehtes Taifersar Arahesis added the comment: Maybe Modules/_ctypes/libffi in 2.7, 3.2 and 3.3 branches should be updated? -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17192 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17201] Use allowZip64=True by default
New submission from Serhiy Storchaka: Python supports ZIP64 extension since 2.5 (more 6 years ago). May be it is time to use it by default, leaving the option to disable it by specifying allowZip64=False. -- components: Library (Lib) messages: 182048 nosy: alanmcintyre, loewis, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Use allowZip64=True by default type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17193] Use binary prefixes
Serhiy Storchaka added the comment: Then I'll apply this to 3.3 too. This will facilitate support of both versions. -- assignee: docs@python - serhiy.storchaka versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Chris Jerdonek added the comment: Senthil, in my experience, whenever documentation is added that documents new aspects of behavior (e.g. is not just a rewording of existing documentation), tests are always added simultaneously (if not already present) to ensure that the code doesn't regress against the new documentation. Todd, DRY means don't repeat yourself. You can look it up on Wikipedia, etc. Identical chunks of code are repeated several times which make it harder for others to see how the test cases differ from each other (as well as making the code harder to maintain). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16278] os.rename documentation slightly inaccurate
Chris Jerdonek added the comment: If it would help I could submit a single patch. Yes, a single patch is best. One way to make code more DRY is refactoring to use helper functions as needed (i.e. same code in multiple places - one helper function). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17189] Add zip64 support to shutil
Serhiy Storchaka added the comment: This should be reflected in the documentation. -- dependencies: +Use allowZip64=True by default ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16612] Integrate Argument Clinic specialized preprocessor into CPython trunk
Bradley Froehle added the comment:
As for the docstring: I would like it better if I could avoid typing
the cumbersome \n\s.
I agree with Stefan that the file is a lot more readable if the docstring
is not repeated twice. It's unfortunate that C doesn't have a notion of
a raw string (as opposed to C++11 with the new R(...) syntax) but I
think it is something we'll have to live with. I would have expected
that a good text editor would be able to convert a selected region into a
C string, but I've never actually seen such a feature.
In general I think we should aim for clarity in scope of the arguments in
the DSL -- either by using curly-braces (a C construct) or indentation (a
Python construct). To minimize the usage of vertical space, I'd like to
see the DSL not require a blank line between arguments.
In a project I worked on recently I ended up writing a parser to go
through a list of C arguments and automatically produce the
PyArg_ParseTuple / PyArg_ParseTupleAndKeywords lines. It's not as
full featured as what we are looking for here, but it did have the
benefit of minimizing the number of extra vertical lines. For example::
static PyObject *
w_rktime(PyObject *self, PyObject *args, PyObject *kwargs)
{
/*[kwargs rktime]*/
darray u;
meshdata msh;
double dt;
int nsteps=1;
/*[/kwargs]*/
static char *_keywords[] = {u, msh, dt, nsteps, NULL};
if (!PyArg_ParseTupleAndKeywords(args, kwargs, OOd|i:rktime,
_keywords, view_as_darray, u, DgMeshData_Converter, msh, dt, nsteps))
return NULL;
/*[checksum=...]*/
...
}
I could imagine extending such a syntax to allow custom converters
and other extensions using comments::
path_t path = PATH_T_INITIALIZE(stat, 0, 1)
/* converter = path_converter; default = None */;
int dir_fd = DEFAULT_DIR_FD
/* converter = OS_STAT_DIR_FD_CONVERTER */;
The biggest downside to this approach would be that the parser could
not inject C code directly into the global scope -- instead it would
be limited to producing #define lines.
-Brad
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16612
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16612] Integrate Argument Clinic specialized preprocessor into CPython trunk
Jim Jewett added the comment: I'm not sure I correctly understand skrah's proposal. If I do, then (1) The first several lines ( /* pymacro.h */ until /* could go into a separate header file */ ) would not be written at all, and are just there to help reviewers understand. (2) The #define OS_STAT_DOC ... line is the docstring, and would be needed, but could easily go into a separate header file, like os_stat__doc.h. For something like cdecimal, there might be only a single _cdecimal__doc.h containing all the docstrings. There might even be a build switch that (at a minimum) replaced anything from those __doc.h files with for space-constrained builds. (3) The human-maintained code would be the DSL between /*[preprocessor] and [preprocessor]*/. (4) The lines between [preprocessor]*/ and /*[preprocessor end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/ would NOT be written or maintained by a human, but WOULD be checked into hg for the benefit builders without the argument-clinic tool. (5) The only C code written or maintained by a human (or another macro system) would be the last 5 lines (the system call, the path cleanup, and the return). If I'm wrong about the above assumptions, then I think your proposal is insufficiently ambitious. If I'm correct, then your proposal boils down to (1) Allow (require?) the function-level docstring to be defined somewhere else, possibly in another file. (2) Change the DSL (2a) Get rid of function flags? (Not sure this is workable) (2b) Replace the (previously proposed) parameter declarations with literal C code forming an array of [parameter kind, array-of-setup-instructions-and-or-magically-named-variable-settings] More flexibility in building the docstring is probably good. The other changes -- I'm not sure I see the advantage, except that it might simplify writing the thing as a C pre-processing macro. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Changes by Serhiy Storchaka storch...@gmail.com: Removed file: http://bugs.python.org/file28954/sax_character_stream.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file29061/sax_character_stream.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file29062/sax_character_stream-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2175] Expat sax parser silently ignores the InputSource protocol
Serhiy Storchaka added the comment: This patch is rather complicated and I doubt whether it is necessary to apply it to the older version. Can anyone review it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10590] Parameter type error for xml.sax.parseString(string, ...)
Changes by Serhiy Storchaka storch...@gmail.com: -- dependencies: +Expat sax parser silently ignores the InputSource protocol ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Changes by Andrew McNabb amcn...@mcnabbs.org: -- nosy: +amcnabb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
