Kiwi PyCon 2013 Call for Proposals is now open! (closes 01 June)
Dear fellow Pythonistas, We're pleased to announce that Kiwi PyCon 2013's Call for Proposals is now open! This year the conference will be held Saturday 06 and Sunday 07 September in Auckland, New Zealand. Friday 05 September will see tutorials and workshops run during the day - a Kiwi PyCon first! The deadline for proposal submission is Saturday 01 June 2013. For more information please visit http://nz.pycon.org/call-for-proposals/ Looking forward to seeing you in Auckland in September! -- Danny W. Adair Event Director Kiwi PyCon 2013 -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: object.enable() anti-pattern
On Fri, 10 May 2013 05:03:10 +, Steven D'Aprano wrote: There is no sensible use-case for creating a file OBJECT unless it initially wraps an open file pointer. So far the only counter-examples given aren't counter-examples ... Well, sure, if you discount operations like create this file and queries like could I delete this file if I wanted to? [0] as methods of the file system rather than of a hypothetical file object. What about a distributed system? Suppose I want to create a file object in one place, and send that object to the another place for the file to be read from or written to [1]? Suppose that for security reasons, I have to do it that way, because the first place can only create the objects, and the second place can only access the underly file contents through an existing object? I suppose that this case exists even in a non-distributed system that allows whatever execution unit exists to change its own security settings (POSIX has setuid and setgid functions), or exposes file ACLs as methods of file objects rather than of the OS or file system. What, exactly, does a file object represent? And going back to your original comment (which was actually in response to one of my posts), at least some operations on python file objects *could* succeed without having to open the file. An OS could provide truncate, or writeable, on un-opened files; and certainly Python could provide encoding, or isatty, on un-opened files. Of these, truncate might be the closest use case of creating a file object without any intent to write to it, for some definition of write to it. Dan [0] Yes, I understand that asking first instead of trying to delete the file is just asking to lose any number of potential race conditions, assuming that your system even supports race conditions. [1] Think about a multi-threaded (or otherwise distributed) FTP or HTTP server. No, don't think about the server vs. the client, but rather a core server overseeing sub servers for different sessions. -- http://mail.python.org/mailman/listinfo/python-list
Re: python call golang
On 10 May 2013 03:37, Thanatos xiao yanxiaopei...@gmail.com wrote: Hey ! Now! I have written a python script . I want to call a golang script in python script. Who can give me some advices? thanks! Check out the subprocess module. You can use it to call other programs from python and get their error codes and output. -- http://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
On Fri, May 10, 2013 at 2:55 PM, Roy Smith r...@panix.com wrote: In article mailman.1523.1368160434.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: The first hard disk I ever worked with stored 20MB in the space of a 5.25 slot (plus its associated ISA controller card). Heh. The first hard disk I ever worked with stored 2.4 MB in 6U of rack space (plus 4 Unibus cards worth of controller). That's not actually the first hard disk I ever used. Just the first one I ever got to touch with my own hands. Did I mention that the air filters had to be changed a few times a year? Uphill both ways, in the snow, while beating off the dinosaurs with sticks. Yeah, I'm pretty young. First computer I ever broke (the same one that had the aforementioned 20MB drive) addressed a whole megabyte of memory, 640KB of which was OK (we're left wondering whether anyone would notice if ROM developed a fault), and I got to play around with 64KB of it in DEBUG.EXE. And yeah, I wrote code straight in DEBUG and saved it and crashed the system. (Tip: If you want to write a device driver, make sure you start with your dad happy with you.) Was good fun. I heartily recommend the exercise, but... uhh... do consider setting up a virtual machine first :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: in need of some help...
On Wednesday, 1 May 2013 13:15:28 UTC+1, Jens Thoms Toerring wrote: Alex Norton ayjayn1...@gmail.com wrote: thanks... ill take a look at the Qt event handling It's rather simple: instead of the program running through a sequence of steps, the program normally is basically doing nothing. It just reacts to events that normally come from the user, i.e. the user clicks on some icon or widget, or (s)he enters something via the keyboard. You etermine which of all the possible events to which widget are relevant to you, write handler functions for them and tell the widget to call some function when an event happens. The simplest case is a button: you want to react to it, so you write a function for what's to be done when it's clicked on and then tell Qt to call that function once it gets clicked (there are different events even for a simple push button, it can be clicked, just pushed, released etc.). And if you have set up everything for that you tell Qt to start waiting for events. So the steps are: 1. Tell Qt that this is a program using it app = QtGui.QApplication( sys.argv ) 2. Create your graphical interface (what you seem to have done more or less) 3. Connect desired events (what's called signals in Qt lingo) for a certain widget to the function to be called with something like your_widget.clicked.connect( your_function ) (replace 'clicked' with e.g. 'pushed' or 'released' when interested in a push or release signal instead) 4. Start the event loop (i.e. have Qt wait for the user to do something and call one of your functions if the user did something you're interested in) with app.exec_( ) When this returns the game is over. So you don't wait for keyboard input with input() like in your original program but instead tell Qt to do the waiting for you and call the appropriate function you defined when something interesting happens. What you probably will have to change about the graphical interface is that instead of using QLabel widgets for 'Air', 'Earth', 'Fire', 'Water' to use e.g. QPushButtons since QLabels are rather static objects - they don't receive any click events and it's rather likely some kind of event like this is what you're going to want to react to. And for that QPushButtons seem to be the simplest choice to start with. So have an 'Air' button (let's call it 'bAir' and then do bAir.clicked.connect( air_clicked ) after defining a function air_clicked() in which you deal with that case. that might be as simple as def air_clicked( ) : # Randomly pick one of 'air', 'fire', 'water' or 'earth' z = [ 'air', 'fire', 'water', earth' ][ random.randrange( 4 ) ] if z == 'air' : print( 'Stalemate' ) elif z == 'water' : print( 'Air removes Water, you win!' ) ... Now, when during the game the 'Air' button is clicked this function will get called. Of course, it might be nicer to have a result label some- where in the graphical interface which you set to the text instead of printing it out to the console. And you also will probably add some Quit button to end the game. Regards, Jens -- \ Jens Thoms Toerring ___ j...@toerring.de \__ http://toerring.de how would i go about adding print outcomes of all options to a label ? -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Fri, 10 May 2013 01:50:09 -0400, Roy Smith wrote: In article 518c7f05$0$29997$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: there is no way to create a C file descriptor in a closed state. Such a thing does not exist. If you have a file descriptor, the file is open. Once you close it, the file descriptor is no longer valid. Of course there is. int fd = 37; I've just created a file descriptor. There is not enough information given to know if it corresponds to an open file or not. No, you haven't created a file descriptor. You've made up a number which C will allow you to use as an index into the file descriptor table, because C is a high-level assembler with very little in the way of type safety, and what little there is you can normally bypass. What you haven't done is create the record in the file descriptor table. You can't expect that read(fd) or write(fd) will work, although both should fail safe rather than segfault if 37 happens to not be an actual file descriptor. What you've done is the moral equivalent of choosing an integer at random, coercing it to a pointer, then dereferencing it to peek or poke at some memory address. (Although fortunately much safer.) It's a nice hack, but not one that takes away from what I'm saying. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Append to python List
Jussi Piitulainen於 2013年5月9日星期四UTC+8下午7時30分05秒寫道： 8 Dihedral writes: This is just the handy style for a non-critical loop. In a critical loop, the number of the total operation counts does matter in the execution speed. Do you use speed often? There is another concern about the list construction part in programming. Although a typical PC is installed with gaga bytes of DRAM now, anything that will use more memory from the heap dynamically could fail in the run time. It is the programmer's job to identify this kind of sources in minds. -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Fri, 10 May 2013 06:22:31 +, Dan Sommers wrote: On Fri, 10 May 2013 05:03:10 +, Steven D'Aprano wrote: There is no sensible use-case for creating a file OBJECT unless it initially wraps an open file pointer. So far the only counter-examples given aren't counter-examples ... Well, sure, if you discount operations like create this file and queries like could I delete this file if I wanted to? [0] as methods of the file system rather than of a hypothetical file object. What about a distributed system? Suppose I want to create a file object in one place, and send that object to the another place for the file to be read from or written to [1]? Suppose that for security reasons, I have to do it that way, because the first place can only create the objects, and the second place can only access the underly file contents through an existing object? Unless you have re-implemented the file I/O system, it doesn't matter. If your file objects are based on C I/O, then even if the first server cannot read or write to the files it still creates file objects in an open state, because that is how C works. Or maybe the first server only creates some sort of proxy to the real underlying file object. Or maybe you're re-implemented the I/O system, and aren't following C's design. Since you're just making this up as a thought experiment, anything is possible. But either way, that's fine. You've found an object where it does make sense to have an explicit make it go method: first one entity has permission to construct the object, but not to open the underlying file. Another entity has permission to open the underlying file, but not to create the object. I have no idea whether this is a reasonable security design or not, it actually sounds a bit rubbish to me but what do I know? So let's treat it as a reasonable design. As I've said, repeatedly, that's not what I'm talking about. When you DON'T have useful things that can be done with the object before calling enable, then it is an anti-pattern to require a separate call to enable method, and the enable functionality should be moved into the object constructor. If you DO have useful things that can be done, like pass the object to another entity, for security, then that's a whole 'nuther story. Really, what I'm describing is *normal* behaviour for most objects. We don't usually design APIs like this: n = int(42) n.enable() m = n + 1 m.enable() x = m*2 + n*3 print x - 1 # oops, raises because I forgot to call x.enable() That's a rubbish API, and for simple data-like objects, we all agree it is a rubbish API. So why accept the same rubbish API just because the object is more complicated? If you don't have a good, reasonable, non- contrived use-case for a separate make it go method, don't use one. For my next controversial opinion, I'm going to argue that we should do arithmetic using numbers rather than by inserting lists inside other lists: # Do this: count = 0 count += 1 # Not this: count = [] count.insert(0, []) *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On 2013-05-10 12:00, Steven D'Aprano wrote: But either way, that's fine. You've found an object where it does make sense to have an explicit make it go method: first one entity has permission to construct the object, but not to open the underlying file. Another entity has permission to open the underlying file, but not to create the object. I have no idea whether this is a reasonable security design or not, it actually sounds a bit rubbish to me but what do I know? So let's treat it as a reasonable design. As I've said, repeatedly, that's not what I'm talking about. When you DON'T have useful things that can be done with the object before calling enable, then it is an anti-pattern to require a separate call to enable method, and the enable functionality should be moved into the object constructor. If you DO have useful things that can be done, like pass the object to another entity, for security, then that's a whole 'nuther story. I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. I think everyone agrees that entirely unmotivated enable methods should be avoided, but I have my doubts that they come up very often. Do programmers have a natural tendency to make an extra, completely unnecessary method? I would think that they have a natural tendency to the opposite. In my experience, everyone has a reason in mind when they follow a pattern/anti-pattern. It is pretty rare that someone just does some specific, nameable thing for no reason at all. There is no need to call out an anti-pattern for which no one has a reason to do it. But there is a continuum of reasons. Some reasons are better than others. Some reasons only apply in a small set of circumstances but seem like they would apply more generally, at least to novice programmers. Programmers can be wrong about what they think the (anti-)pattern actually achieves. The whole point of naming an anti-pattern is to discuss those reasons, show where they are misapplied, where YAGNI, why novices overuse it, other patterns that should be used instead, and also the circumstances where it is actually a good pattern instead. To artificially limit the discussion of the anti-pattern to the trivial, entirely unmotivated case forbids most of the interesting and instructive parts of the conversation. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
On May 10, 2013, at 12:55 AM, Roy Smith r...@panix.com wrote: In article mailman.1523.1368160434.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: The first hard disk I ever worked with stored 20MB in the space of a 5.25 slot (plus its associated ISA controller card). Heh. The first hard disk I ever worked with stored 2.4 MB in 6U of rack space (plus 4 Unibus cards worth of controller). That's not actually the first hard disk I ever used. Just the first one I ever got to touch with my own hands. Sounds suspiciously like an RK05. We used a lot of those on DEC PDP-8e's. I can remember how startled I was when I first saw a DEC engineer pull the top off one and then, with it open, spin it up. The platter inside was warped (a ceiling light reflected off the platter wiggled and then blurred) but the head mechanism actually just followed it up and down!!! Bill Did I mention that the air filters had to be changed a few times a year? Uphill both ways, in the snow, while beating off the dinosaurs with sticks. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: help on Implementing a list of dicts with no data pattern
On 2013-05-09, Dave Angel da...@davea.name wrote: On 05/09/2013 05:22 PM, rlelis wrote: On Thursday, May 9, 2013 7:19:38 PM UTC+1, Dave Angel wrote: Yes it's a list of string. I don't get the NameError: name 'file_content' is not defined in my code. That's because you have the 3 lines below which we hadn't seen yet. Heroic efforts, Dave! To rlelis: Do not start to program until you understand what you want to do. Work it out on a sheet of paper, or at least in your mind. If you can't provide sample input and the expected output from it, chances are you aren't ready to start writing code. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
On May 10, 2013, at 7:49 AM, William Ray Wing wrote: On May 10, 2013, at 12:55 AM, Roy Smith r...@panix.com wrote: In article mailman.1523.1368160434.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: The first hard disk I ever worked with stored 20MB in the space of a 5.25 slot (plus its associated ISA controller card). Heh. The first hard disk I ever worked with stored 2.4 MB in 6U of rack space (plus 4 Unibus cards worth of controller). That's not actually the first hard disk I ever used. Just the first one I ever got to touch with my own hands. Sounds suspiciously like an RK05. Yup. -- Roy Smith r...@panix.com -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article 518cc239$0$29997$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
int fd = 37;
I've just created a file descriptor. There is not enough information
given to know if it corresponds to an open file or not.
No, you haven't created a file descriptor. You've made up a number which
C will allow you to use as an index into the file descriptor table,
because C is a high-level assembler with very little in the way of type
safety, and what little there is you can normally bypass.
No, I've created a file descriptor, which is, by definition, an integer.
It has nothing to do with C. This is all defined by the POSIX
interface. For example, the getdtablesize(2) man page says:
The entries in the descriptor table are numbered with small integers
starting at 0. The call getdtablesize() returns the size of this table.
So, I am now guaranteed that fds will be ints. I also know the
guaranteed minimum and maximum values.
The system even makes certain guarantees which let me predict what file
descriptor I'll get next in certain situations. For example, from the
dup(2) page on my OSX box:
The new descriptor returned by the call is the lowest numbered
descriptor currently not in use by the process.
What you haven't done is create the record in the file descriptor table.
That's correct. But, as described above, the system makes certain
guarantees which allow me to reason about the existence or non-existence
os such entries.
You can't expect that read(fd) or write(fd) will work
I can expect that they will work if I have reasoned correctly about the
POSIX-guaranteed semantics. For example, POSIX says(*) that this C
program is guaranteed to print, hello, fd world (assuming the
assertion passes):
#include unistd.h
#include stdio.h
#include string.h
#include assert.h
int main(int argc, char** argv) {
int max_files = getdtablesize();
assert(max_files = 4);
for (int i = 3; i max_files; ++i) {
close(i);
}
dup(2);
char* message = hello, fd world\n;
write(3, message, strlen(message));
}
What you've done is the moral equivalent of choosing an integer at
random, coercing it to a pointer, then dereferencing it to peek or poke
at some memory address. (Although fortunately much safer.)
No, what I've done is taken advantage of behaviors which are guaranteed
by POSIX.
But, we're going off into the weeds here. Where this started was you
said:
There is no sensible use-case for creating a file WITHOUT OPENING
it. What would be the point?
I agree with you, in general, that it is usually poor design to have
classes which require instances to be initialized after they are created.
The problem is, you chose as your example a particular domain where the
underlying objects being modeled have unusual semantics imposed by an
interface that's 40 years old. And then you made absolute statements
about there not possibly ever being certain use cases, when clearly
there are (for that domain).
---
(*) Technically, getdtablesize() isn't POSIX, but POSIX does define
other ways to get the same information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article mailman.1527.1368188358.3114.python-l...@python.org, Robert Kern robert.k...@gmail.com wrote: I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. I think everyone agrees that entirely unmotivated enable methods should be avoided, but I have my doubts that they come up very often. As I mentioned earlier in this thread, this was a common pattern in the early days of C++, when exceptions were a new concept and handled poorly by many compilers (and, for that matter, programmers). There was a school of thought that constructors should never be able to fail (because the only way for a constructor to fail is to throw an exception). The pattern was to always have the constructor succeed, and then either have a way to check to see if the newly-constructed object was valid, or have a separate post-construction initialization step which could fail. See, for example, the isValid() and Exists() calls for RogueWave's RWFile class (http://tinyurl.com/c8kv26g). And also, http://tinyurl.com/cgs6clx. Even today, there are C++ implementations which do not use exceptions. Some are for use in embedded or real-time systems where things need to be strictly time-bound and/or memory-bound. Others are for historical reasons (http://tinyurl.com/6hn4zo). Once people were used to writing can't fail constructors in C++, they often continued using that pattern in other languages, where the underlying reasons no longer made sense. Quite possibly, they never even knew the underlying reasons; they were taught, Constructors must never fail, and assumed it was a universal rule. This, BTW, is one of my biggest beefs with the classic Gang Of Four pattern book. It presents a bunch of patterns as being universally applicable, when in reality many (if not most) of them are highly C++ specific. BTW, whenever I read things like, I think everyone agrees, I automatically assume what the writer really meant was, I, and all the people who agree with me, think. -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On 10 May 2013 15:01, Roy Smith r...@panix.com wrote: In article mailman.1527.1368188358.3114.python-l...@python.org, Robert Kern robert.k...@gmail.com wrote: I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. I think everyone agrees that entirely unmotivated enable methods should be avoided, but I have my doubts that they come up very often. As I mentioned earlier in this thread, this was a common pattern in the early days of C++, when exceptions were a new concept and handled poorly by many compilers (and, for that matter, programmers). There was a school of thought that constructors should never be able to fail (because the only way for a constructor to fail is to throw an exception). The pattern was to always have the constructor succeed, and then either have a way to check to see if the newly-constructed object was valid, or have a separate post-construction initialization step which could fail. It's not just because of exceptions. In C++ virtual method calls in a constructor for a class A will always call the methods of class A even if the object being constructed is actually of a subclass B because the B part of the object isn't initialised when the A constructor is called. There may be a better way to do this since I last used C++ but as I remember it the two-phase pattern was a recommended way to implement polymorphic behaviour during initialisation. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article mailman.1530.1368196163.3114.python-l...@python.org, Oscar Benjamin oscar.j.benja...@gmail.com wrote: It's not just because of exceptions. In C++ virtual method calls in a constructor for a class A will always call the methods of class A even if the object being constructed is actually of a subclass B because the B part of the object isn't initialised when the A constructor is called. There may be a better way to do this since I last used C++ but as I remember it the two-phase pattern was a recommended way to implement polymorphic behaviour during initialisation. Mind. Blown. One of the things I love (FSVO love) about C++ is that no matter how much I learn, there's always whole new areas of wonderment to explore behind doors I didn't even know existed. Thank you. I suppose, if I had a class like this, I would write a factory function which called the constructor and post-construction initializer. And then I would make the constructor protected. -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com wrote: I suppose, if I had a class like this, I would write a factory function which called the constructor and post-construction initializer. And then I would make the constructor protected. That sounds like a reasonable plan, with the possible exception of protected. Since meeting Python, I've stopped using private and protected anywhere. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article mailman.1531.1368197225.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com wrote: I suppose, if I had a class like this, I would write a factory function which called the constructor and post-construction initializer. And then I would make the constructor protected. That sounds like a reasonable plan, with the possible exception of protected. Since meeting Python, I've stopped using private and protected anywhere. ChrisA Each language has its own set of best practices. Trying to write C++ code using Python patterns is as bad as trying to write Python code using C++ patterns. -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Sat, May 11, 2013 at 12:54 AM, Roy Smith r...@panix.com wrote:
In article mailman.1531.1368197225.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Sat, May 11, 2013 at 12:37 AM, Roy Smith r...@panix.com wrote:
I suppose, if I had a class like this, I would write a factory function
which called the constructor and post-construction initializer. And
then I would make the constructor protected.
That sounds like a reasonable plan, with the possible exception of
protected. Since meeting Python, I've stopped using private and
protected anywhere.
ChrisA
Each language has its own set of best practices. Trying to write C++
code using Python patterns is as bad as trying to write Python code
using C++ patterns.
Agreed, in generality. But what is actually gained by hiding data from
yourself? Compare:
class Foo
{
int asdf;
public:
Foo(int _asdf):asdf(_asdf) {}
int get_asdf() {return asdf;}
void set_asdf(int _asdf) {asdf=_asdf;}
void frob() {printf(Hi, I am %d\n,asdf);}
};
struct Foo
{
int asdf;
Foo(int _asdf):asdf(_asdf) {}
void frob() {printf(Hi, I am %d\n,asdf);}
};
Is there anything worse about the second one? Oh, and by logical
extension, here's something that doesn't (AFAIK) work in C++, but does
in another language that's syntactically similar:
class Foo(int asdf)
{
void frob() {write(Hi, I am %d\n,asdf);}
}
Now that's brevity. Why bother saying what's patently obvious? (Pike's
class keyword is like C++'s struct, members are public by
default.)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On Sat, May 11, 2013 at 1:06 AM, jmfauth wxjmfa...@gmail.com wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. By the skywriter, or by the two on the ground, or by Randall Munroe? Or by jmf? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Anybody familiar with pygments ?
On Thu, May 9, 2013 at 10:40 AM, Fábio Santos fabiosantos...@gmail.com wrote: On 9 May 2013 05:19, dabaichi valben...@outlook.com wrote: And hereis the output file: That's not the output file. That is just an HTML fragment to put on your page. A full HTML file will need more things, which is the reason why you don't see color output. I want to know why output html file with no color ? Because there is no CSS. The output has a lot of span tags with classes. You are supposed to use a CSS file along with it. So, first put that output into a complete HTML document (with a head, a body...) And in that document add or link to your CSS file with the color information. I never used pygments but there may be some readily available. -- http://mail.python.org/mailman/listinfo/python-list First off, the Python code was unnecessary in this case, because it would be cheaper to use the pygmentize app included. Second off, CSS is available at https://github.com/richleland/pygments-css or by running `pygmentize -f html -O full FILE`. -- Kwpolska http://kwpolska.tk | GPG KEY: 5EAAEA16 stop html mail| always bottom-post http://asciiribbon.org| http://caliburn.nl/topposting.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On 5/10/2013 11:06 AM, jmfauth wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf And this reflects a lack of a sense of humor. :) --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article mailman.1532.1368198547.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Each language has its own set of best practices. Trying to write C++ code using Python patterns is as bad as trying to write Python code using C++ patterns. Agreed, in generality. But what is actually gained by hiding data from yourself? You're not hiding it from yourself. You're hiding it from the other people who are using your code and may not understand all the subtle gotchas as well as you do. In the calling-virtual-methods-in-the-constructor case we're talking about here, constructing an object by calling B() without immediately following it up with a call to B::PostInit() is dangerous. If you document that you shouldn't do that, but allow it anyway, people will do it. Better to disallow it completely. People will bitch when their code doesn't compile, but that's better than compiling and running and producing the wrong results. You solve this problem in Python by simply having the constructor do the right thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On Sat, May 11, 2013 at 1:24 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 5/10/2013 11:06 AM, jmfauth wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf And this reflects a lack of a sense of humor. :) Isn't that a crime in the UK? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On 2013-05-10 15:01, Roy Smith wrote: In article mailman.1527.1368188358.3114.python-l...@python.org, Robert Kern robert.k...@gmail.com wrote: I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. I think everyone agrees that entirely unmotivated enable methods should be avoided, but I have my doubts that they come up very often. As I mentioned earlier in this thread, this was a common pattern in the early days of C++, when exceptions were a new concept and handled poorly by many compilers (and, for that matter, programmers). There was a school of thought that constructors should never be able to fail (because the only way for a constructor to fail is to throw an exception). The pattern was to always have the constructor succeed, and then either have a way to check to see if the newly-constructed object was valid, or have a separate post-construction initialization step which could fail. See, for example, the isValid() and Exists() calls for RogueWave's RWFile class (http://tinyurl.com/c8kv26g). And also, http://tinyurl.com/cgs6clx. Even today, there are C++ implementations which do not use exceptions. Some are for use in embedded or real-time systems where things need to be strictly time-bound and/or memory-bound. Others are for historical reasons (http://tinyurl.com/6hn4zo). Once people were used to writing can't fail constructors in C++, they often continued using that pattern in other languages, where the underlying reasons no longer made sense. Quite possibly, they never even knew the underlying reasons; they were taught, Constructors must never fail, and assumed it was a universal rule. Right, this is one of the bad reasons I talk about later in my message. The authors had a reason in their mind for doing it (they thought it was a universal rule); it was just a bad one. It's more useful to talk about why people thought they should follow that pattern than to just say there is no reason to do this. This, BTW, is one of my biggest beefs with the classic Gang Of Four pattern book. It presents a bunch of patterns as being universally applicable, when in reality many (if not most) of them are highly C++ specific. BTW, whenever I read things like, I think everyone agrees, I automatically assume what the writer really meant was, I, and all the people who agree with me, think. Hah! Fair enough. I actually meant it to emphasize that I thought that Steven was overly reducing his statements to something that was trivially true, sacrificing content for validity. I will suggest that your interpretation of that phrase is more appropriate when the speaker is proposing something of their own rather than (partially) conceding a point. The exaggeration is only self-aggrandizing in the former case. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Sat, May 11, 2013 at 1:21 AM, Roy Smith r...@panix.com wrote: In article mailman.1532.1368198547.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: Agreed, in generality. But what is actually gained by hiding data from yourself? You're not hiding it from yourself. You're hiding it from the other people who are using your code and may not understand all the subtle gotchas as well as you do. True. And on looking over my code, I find that there are a few cases where I've used private members: I have a buffer class that acts pretty much like a non-refcounted string, and it declares a private copy constructor to prevent accidental misuse. But it's the exception, not the rule. My main point isn't about the cases where you actually want to prevent access, but the all-too-common case where the member itself is private and there are two public methods to get and set it. Massive boilerplate. Completely unnecessary in 99%+ of cases. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On May 10, 8:32 pm, Chris Angelico ros...@gmail.com wrote: On Sat, May 11, 2013 at 1:24 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 5/10/2013 11:06 AM, jmfauth wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf And this reflects a lack of a sense of humor. :) Isn't that a crime in the UK? ChrisA The problem with English humour (as against standard humor) is that its not unicode compliant -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On 10/05/2013 17:07, rusi wrote: On May 10, 8:32 pm, Chris Angelico ros...@gmail.com wrote: On Sat, May 11, 2013 at 1:24 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 5/10/2013 11:06 AM, jmfauth wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf And this reflects a lack of a sense of humor. :) Isn't that a crime in the UK? ChrisA The problem with English humour (as against standard humor) is that its not unicode compliant British humour includes double entendre, which is not French-compliant. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode humor
On 05/10/2013 09:07 AM, rusi wrote: On May 10, 8:32 pm, Chris Angelico ros...@gmail.com wrote: On Sat, May 11, 2013 at 1:24 AM, Ned Batchelder n...@nedbatchelder.com wrote: On 5/10/2013 11:06 AM, jmfauth wrote: On 8 mai, 15:19, Roy Smith r...@panix.com wrote: Apropos to any of the myriad unicode threads that have been going on recently: http://xkcd.com/1209/ -- This reflects a lack of understanding of Unicode. jmf And this reflects a lack of a sense of humor. :) Isn't that a crime in the UK? ChrisA The problem with English humour (as against standard humor) is that its not unicode compliant Is so! It fits inside the first 127 code points!! As a bonus it also takes less brain power^H^H^H^H^H^H^H^H^H space. ;) -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Thu, 09 May 2013 05:23:59 +, Steven D'Aprano wrote: There is no sensible use-case for creating a file without opening it. What would be the point? Any subsequent calls to just about any method will fail. Since you have to open the file after creating the file object anyway, why make them two different calls? As a counterpoint, some OSes (e.g. Plan 9) allow you to get a handle to a file without opening it. This can then be used for deleting, renaming or stat()-type operations without either the risk of race conditions (if another process renames files between operations, the operations may be performed on different files) or the side-effects of actually opening the file (particularly for device files, e.g. opening a tape drive may rewind the tape). Python's file model doesn't allow for this, so there isn't really anything meaningful that you can do on a file object which isn't open (although these actually exist; any file object on which the .close() method has been called will be in this state). However: there are situations where it is useful to be able to separate the simple task of creating an object from more invasive actions such as system calls. Particularly in multi-threaded or real-time code (although the latter is a non-starter in Python for many other reasons). -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
10.05.13 15:19, Robert Kern написав(ла): I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. Many (if not most) GUI frameworks use this pattern. button = Button(text) button.setForegroundColor(...) button.setBackgoundColor(...) button.setFont(...) button.setRelief(...) button.setBorder(...) button.setWidth(...) button.setAction(...) button.setMouseListener(...) button.place(...) Another example is running a subprocess in Unix-like systems. fork() open/close file descriptors, set limits, etc exec*() -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On 2013-05-10 16:44, Serhiy Storchaka wrote: 10.05.13 15:19, Robert Kern написав(ла): I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. Many (if not most) GUI frameworks use this pattern. button = Button(text) button.setForegroundColor(...) button.setBackgoundColor(...) button.setFont(...) button.setRelief(...) button.setBorder(...) button.setWidth(...) button.setAction(...) button.setMouseListener(...) button.place(...) Another example is running a subprocess in Unix-like systems. fork() open/close file descriptors, set limits, etc exec*() According to Steven's criteria, neither of these are instances of the anti-pattern because there are good reasons they are this way. He is reducing the anti-pattern to just those cases where there is no reason for doing so. That is why I asked for in-the-wild instances. I should have qualified my sentence to include according to your criteria because people seem to be answering my query out of that context. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On Sat, May 11, 2013 at 1:44 AM, Serhiy Storchaka storch...@gmail.com wrote: 10.05.13 15:19, Robert Kern написав(ла): I'd be curious to see in-the-wild instances of the anti-pattern that you are talking about, then. Many (if not most) GUI frameworks use this pattern. button = Button(text) button.setForegroundColor(...) button.setBackgoundColor(...) button.setFont(...) button.setRelief(...) button.setBorder(...) button.setWidth(...) button.setAction(...) button.setMouseListener(...) button.place(...) The button really exists, though. You could merge the creation and placement (or in the case of a window/dialog, the creation and showing), but it's often useful to not. However, in the specific case you have there, there's an alternative: a mapping of attributes and values passed to the constructor, and then you could pass the constructed object directly to a place(). That would let you, if you wished, effectively construct a Button with a parent right there, which makes reasonable sense. Another example is running a subprocess in Unix-like systems. fork() open/close file descriptors, set limits, etc exec*() Hrm. Not really a corresponding example. After you fork, you have two actual processes. Following up with an exec is only one of the possible options; I've done code that forks and execs, and code that forks and keeps running, and neither of them feels wrong in any way. There IS a function that's similar to what you're saying, and that's vfork: (From POSIX.1) The vfork() function has the same effect as fork(2), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully calling _exit(2) or one of the exec(3) family of functions. It's deprecated because it's so fragile (and because regular fork() isn't that much less efficient now; AIUI, vfork was meant to be a lightweight fork). I would say that the deprecation of vfork in favour of fork is a strong indication that the object.enable() anti-pattern can come up in kernel APIs too, and isn't liked there either. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
In article pan.2013.05.10.16.59.31.512...@nowhere.com, Nobody nob...@nowhere.com wrote: However: there are situations where it is useful to be able to separate the simple task of creating an object from more invasive actions such as system calls. Particularly in multi-threaded or real-time code (although the latter is a non-starter in Python for many other reasons). Sure. I can serialize a path name. I can't serialize an open file descriptor. -- http://mail.python.org/mailman/listinfo/python-list
?????????? WHY DID PROPHET MUHAMMAD MARRY AISHA THE YOUNG GIRL
WHY DID PROPHET MUHAMMAD MARRY AISHA THE YOUNG GIRL? This is an important book talks about a common issue misunderstood but misused by lots of thinkers and orientalists. It is “Why did Prophet Muhammad marry Aisha the young girl?” The author shows the reason behind their discussion. They want to distort the picture of Prophet Muhammad not criticize the marriage of young girl. Also if this kind of marriage was strange, why did not the disbelievers of Quraish use it as a pretext against Muhammad?! The author discusses other topics such as: Europe also allows marrying young girls, the age of consent in most countries worldwide. http://www.islamhouse.com/330161/en/en/books/Why_Did_Prophet_Muhammad_Marry_Aisha_the_Young_Girl? thank you -- http://mail.python.org/mailman/listinfo/python-list
Re: python call golang
Now! I have written a python script . I want to call a golang script in python script. Who can give me some advices? See http://gopy.qur.me/extensions/examples.html and http://www.artima.com/weblogs/viewpost.jsp?thread=333589 -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
On 10May2013 09:22, Roy Smith r...@panix.com wrote: | In article 518cc239$0$29997$c3e8da3$54964...@news.astraweb.com, | Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: | int fd = 37; | | I've just created a file descriptor. There is not enough information | given to know if it corresponds to an open file or not. | | No, you haven't created a file descriptor. You've made up a number which | C will allow you to use as an index into the file descriptor table, | because C is a high-level assembler with very little in the way of type | safety, and what little there is you can normally bypass. | | No, I've created a file descriptor, which is, by definition, an integer. | It has nothing to do with C. This is all defined by the POSIX | interface. For example, the getdtablesize(2) man page says: | | The entries in the descriptor table are numbered with small integers | starting at 0. The call getdtablesize() returns the size of this table. [... snip ...] I'm with Steven here. You've made a number that can be used with calls that access the OS file descriptor table. But it isn't a file descriptor. (Yes, the in-program number is just a number either way.) The descriptor table is an in-kernel data structure, filled with file descriptors. All you have is a label that may or may not access a file descriptor. Anyway, we all know _what_ goes on. We're just having terminology issues. Cheers, -- Cameron Simpson c...@zip.com.au My computer always does exactly what I tell it to do but sometimes I have trouble finding out what it was that I told it to do. - Dick Wexelblat r...@ida.org -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
There is no sensible use-case for creating a file OBJECT unless it initially wraps an open file pointer. So far the only counter-examples given aren't counter-examples ... Well, sure, if you discount operations like create this file and queries like could I delete this file if I wanted to? [0] as methods of the file system rather than of a hypothetical file object. What about a distributed system? Suppose I want to create a file object in one place, and send that object to the another place for the file to be read from or written to [1]? Suppose that for security reasons, I have to do it that way, because the first place can only create the objects, and the second place can only access the underly file contents through an existing object? Unless you have re-implemented the file I/O system, it doesn't matter. If your file objects are based on C I/O, then even if the first server cannot read or write to the files it still creates file objects in an open state, because that is how C works. Or maybe the first server only creates some sort of proxy to the real underlying file object. Or maybe you're re-implemented the I/O system, and aren't following C's design. Since you're just making this up as a thought experiment, anything is possible. But either way, that's fine. You've found an object where it does make sense to have an explicit make it go method: first one entity has permission to construct the object, but not to open the underlying file. Another entity has permission to open the underlying file, but not to create the object. I have no idea whether this is a reasonable security design or not, it actually sounds a bit rubbish to me but what do I know? So let's treat it as a reasonable design. As I've said, repeatedly, that's not what I'm talking about. When you DON'T have useful things that can be done with the object before calling enable, then it is an anti-pattern to require a separate call to enable method, and the enable functionality should be moved into the object constructor. If you DO have useful things that can be done, like pass the object to another entity, for security, then that's a whole 'nuther story. You're missing one other case: if there's useful things that can be checked before calling enable(). Remember, on multi-user and/or multi-processing systems, there could be contention for a slow resource. If you automatically open a file for write, you're preventing everyone else from writing and potentially reading it. So there is something useful: did that file exist? Is that resource available for writing? Prior to such hi-level languages like Python and reliable hardware, such fine-grained control was important and vital. Now it can probably be relegated to special OS libraries. Mark Really, what I'm describing is *normal* behaviour for most objects. We don't usually design APIs like this: n = int(42) n.enable() m = n + 1 m.enable() x = m*2 + n*3 print x - 1 # oops, raises because I forgot to call x.enable() Again, you only do that for shared resources. In this case, memory would have to be a (protected) shared resources, but the OS manages memory allocation, so it's not an issue. Mark That's a rubbish API, and for simple data-like objects, we all agree it is a rubbish API. So why accept the same rubbish API just because the object is more complicated? I think I just told you, but let me know . :) For my next controversial opinion, I'm going to argue that we should do arithmetic using numbers rather than by inserting lists inside other lists: Try arguing that we should have a common message-passing syntax. # Do this: count = 0 count += 1 # Not this: count = [] count.insert(0, []) That's actually what they do in set theory, believe it or not. MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
| No, I've created a file descriptor, which is, by definition, an integer. | It has nothing to do with C. This is all defined by the POSIX | interface. For example, the getdtablesize(2) man page says: | | The entries in the descriptor table are numbered with small integers | starting at 0. The call getdtablesize() returns the size of this table. [... snip ...] I'm with Steven here. You've made a number that can be used with calls that access the OS file descriptor table. But it isn't a file descriptor. (Yes, the in-program number is just a number either way.) Steven, don't be misled. POSIX is not the model to look to -- it does not acknowledge that files are actual objects that reside on a piece of hardware. It is not simply an integer. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
Am 10.05.2013 15:22 schrieb Roy Smith:
That's correct. But, as described above, the system makes certain
guarantees which allow me to reason about the existence or non-existence
os such entries.
Nevertheless, your 37 is not a FD yet.
Let's take your program:
#include unistd.h
#include stdio.h
#include string.h
#include assert.h
int main(int argc, char** argv) {
int max_files = getdtablesize();
assert(max_files = 4);
Until here, the numbers 3 toll max_files may or may not be FDs.
for (int i = 3; i max_files; ++i) {
close(i);
}
Now they are closed; they are definitely no longer FDs even if they
were. If you would use them in a file operation, you'd get a EBADF which
means fd is not a valid file descriptor.
dup(2);
From now on, 3 is a FD and you can use it as such.
char* message = hello, fd world\n;
write(3, message, strlen(message));
}
No, what I've done is taken advantage of behaviors which are guaranteed
by POSIX.
Maybe, but the integer numbers get or los their property as a file
descriptor with open() and close() and not by assigning them to an int.
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
[issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)
Serhiy Storchaka added the comment: if (PyLong_CheckExact(item) || (PyLong_Check(item) item-ob_type-tp_as_number-nb_index == PyLong_Type.tp_as_number-nb_index)) -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17883] Fix buildbot testing of Tkinter
Martin v. Löwis added the comment: a) Is Windows Server 2003 is really meant to be spported? Yes b) Are UNCs expected to behave differently on Server 2003? No. c) Can UNCs be disabled on a particular machine? I may misunderstand can: yes, it is possible, but no, it is not desirable. Zach: Temporarily committing changes to test specific buildbot issues is fine; asking the slave operator for direct access to the machine may also work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17883 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
New submission from Ethan Furman: PEP-0435 has been approved! Now for lots of code review. -- assignee: docs@python components: Documentation, Library (Lib), Tests files: ref435.py hgrepos: 189 messages: 188812 nosy: barry, docs@python, eli.bendersky, stoneleaf priority: normal severity: normal status: open title: Code, test, and doc review for PEP-0435 Enum versions: Python 3.4 Added file: http://bugs.python.org/file30191/ref435.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17841] Remove missing aliases from codecs documentation
Nick Coghlan added the comment: For anyone else reading the issue and wondering about Ezio's question above - this issue was actually spun out from issue 7475, which covers the long saga of getting these codecs fully restored in the new world order of Python 3 :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17841 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti stage: - patch review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Ezio Melotti added the comment: Can you upload the patch as a diff against the CPython repo? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Ethan Furman added the comment: Here it is (I hope ;) . -- keywords: +patch Added file: http://bugs.python.org/file30192/pep-435.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17948] HTTPS and sending a big file size hangs.
New submission from Jesús Vidal Panalés: This bug was found using Mercurial. All the information it's on this bug link http://bz.selenic.com/show_bug.cgi?id=3905 The bug was introduced on 2.7.3, previous versions works fine. -- components: Windows messages: 188816 nosy: jesusvpct priority: normal severity: normal status: open title: HTTPS and sending a big file size hangs. type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK
Xavier de Gaye added the comment: For the reson why read() must still check for EWOULDBLOCK even though after select() has reported a file descriptor ready for reading, see the BUGS section of select linux man page, which says: Under Linux, select() may report a socket file descriptor as ready for reading, while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block. -- nosy: +xdegaye ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Antoine Pitrou added the comment: TBH I would *love* for there to be a standardized way to extend the command line options! If it existed I would help myself. As it is, that's way to complicated. (Then again, most customizations to the default test runner are too complicated IMO. :-) +1. I found myself wanting to add a -F option à la regrtest, and I ended up processing sys.argv manually :-/ -- title: Unittest runner needs an option to call gc.collect() after each test - Unittest runner needs an option to call gc.collect() after each test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17948] HTTPS and sending a big file size hangs.
Antoine Pitrou added the comment: Hello Jesus, this report is far too vague to make anything about it. You should try to diagnose the issue further, here are some ideas: - check whether it happens with another server than IIS - try if you can reproduce without Mercurial being involved (simply write a script using httplib or urllib2 to push a file to the server) - try to see what happens over the wire using e.g. Wireshark Bonus points if you can find an easy way to reproduce, short of hosting a large Mercurial repo on a Windows server :-) -- components: +Library (Lib) nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17936] O(n**2) behaviour when adding/removing classes
Kristján Valur Jónsson added the comment: So, any objections? It is pretty straighforward. Btw, the searching for Py_NONE seems to be a rudiment of some older version, there is no place where a Py_NONE is put in there. Also, what is the policy for 2.7? Are performance bugs proper bugs? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK
Xavier de Gaye added the comment: Deciding what's best to do at this point without breaking existent code is not easy, that is why I think that on python = 3.3 we should fix *asynchat* in order to take EAGAIN/EWOULDBLOCK into account and leave asyncore's recv() alone. IMHO for all python versions, asynchat should be fixed and recv() left unchanged raising OSError with EAGAIN/EWOULDBLOCK. With the proposed change on recv(), asyncore users would need to handle this new None returned value anyway, instead of handling the exception which is much more explicit. The attached patch does this on the default branch. -- Added file: http://bugs.python.org/file30193/EWOULDBLOCK.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Hi again, sorry for being a bit late in following up to this. Here are the results for the two runs you requested; these were done on the same machine, intermixed (the first one cache-clean, the second and third run subsequently (so that the third run is cache-filled)). I used static builds. For the “without assert”, I get approximately 570 usec per loop consistently: (590,580), (570,570), (560,580), (570,560) Interestingly enough, there seems to be no preference either way (ASCII or UTF-8). For the “without the whole if‥endif block”, I get mixed results: (650,540), (690,530), (520,530), (650,540) Interesting here is that the third run of them both has a lower ASCII than UTF-8 time, the others don’t – but the UTF-8 run is the second in a row, so cache might be of an issue. Repeating the runs, I get (560,590), (540,530) for the second case, and (760,570), (590,660) for the first case breaking its “consistently 570 usec” streak. Error of measurement may be large, thus. Which supports your suspicion that the optimised case may not be needed at all. Matthias asked me to provide links how to set up an Atari VM with Debian unstable and a clean/minimal unstable chroot, since there’s much use of Ubuntu here who ship ARAnyM (I even filed a Sync Request so that the latest release got a fixed version ☺). https://wiki.debian.org/Aranym/Quick#download has got pointers for the first part (setting up an ARAnyM VM), and https://wiki.debian.org/M68k/Installing contains the whole documentation (we cannot currently use d-i but people are working on it). http://people.debian.org/~tg/f/20121227/m68k-buildd.tgz is the output of “debootstrap --variant=buildd” and as such should be usable in either cowbuilder or sbuild. Considering that we *only* have unstable available, you may want to be careful when upgrading ;) but an apt-get update should work out of the box (takes a few minutes). The VMs have 768+14 MiB RAM each in the sample configuration (maxed out), which makes them use a bit less than 1 GiB on the host side. A 3 GHz host CPU is of benefit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17936] O(n**2) behaviour when adding/removing classes
Antoine Pitrou added the comment: Py_None is what PyWeakref_GET_OBJECT() returns when the object is dead. (same as calling () on a weakref, really) The patch looks straightforward to me. 2.7 doesn't receive performance fixes, though, except for large regressions. Also, we've had enough regressions in the last 2.7 bugfix release, IMHO. (I had worked on a patch which replaced the list with a dict, but I had refcounting issues with it, and I'm not interested enough in the issue to push any further) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t)
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9687 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17926] PowerLinux dbm failure in 2.7
Serhiy Storchaka added the comment: See also issue9687. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17936] O(n**2) behaviour when adding/removing classes
Kristján Valur Jónsson added the comment: Right, I misread the code. Since the remove_subclass() function is called when a subclass dies, I don't think it is necessary to clear out weak references in add_subclass(). They are there merely to break the reference cycle. Btw, the 'patch diff' stuff seems to be broken in the tracker -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t)
Antoine Pitrou added the comment: Should be fixed in issue17926. AFAICT the issue doesn't exist on 3.x. -- resolution: - duplicate stage: patch review - committed/rejected status: open - closed superseder: - PowerLinux dbm failure in 2.7 versions: -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9687 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17936] O(n**2) behaviour when adding/removing classes
Antoine Pitrou added the comment: Right, I misread the code. Since the remove_subclass() function is called when a subclass dies, I don't think it is necessary to clear out weak references in add_subclass(). They are there merely to break the reference cycle. Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5773] Crash on shutdown after os.fdopen(2) in debug builds
Anselm Kruis added the comment: Hi, I was faced with a very similar problem also caused by an invalid file descriptor. My solution is to set an invalid parameter handler, that does nothing. This effectively disables Dr. Watson. Perhaps this is a suitable solution for other users too. And it does not require a patch. def set_invalid_parameter_handler(flag): Set the MSVCRT invalid parameter handler. If flag is True, this function sets an invalid parameter handler, that does nothing. This effectively disables Dr. Watson. If flag is an integer number, it must be the address of an invalid parameter handler function. If flag is None, this function removes the invalid parameter handler. This effectively enables Dr. Watson. The return value is the address of the current handler or None, if no handler is installed. Example:: old = set_invalid_parameter_handler(True) try: do_something_nasty finally: set_invalid_parameter_handler(old) try: # get the msvcrt library import ctypes.util libc = ctypes.util.find_msvcrt() if not libc: # probably not windows return None libc = getattr(ctypes.cdll, libc) siph = libc._set_invalid_parameter_handler siph.restype = ctypes.c_void_p siph.argtypes = [ ctypes.c_void_p ] # now we need a suitable handler. # The handler must simply return without performing any actions. # Of course there is none. # But if we look at the calling convention (cdecl), and # at the fact, that we don't need the argument values # we find, that we can call any function, as long as the function # does not harm. A suitable function is int abs(abs). null_handler = libc.abs except Exception: # probably not the correct windows version return None if flag is True: flag = null_handler return siph(flag) -- nosy: +anselm.kruis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5773 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Antoine Pitrou added the comment: Which supports your suspicion that the optimised case may not be needed at all. So we can just skip the assert when __m68k__ is defined? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
Serhiy Storchaka added the comment: Could you please repeat the tests with a larger data (1MB or more)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Serhiy Storchaka added the comment: So what about more compact Struct object? This is not only memory issue (a Struct object can require several times larger memory than size of processed data), but performance issue (time of creating such object is proportional to it's size). Here is a patch with updated __sizeof__ method and tests. -- Added file: http://bugs.python.org/file30194/struct_repeat_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Changes by Eli Bendersky eli...@gmail.com: Removed file: http://bugs.python.org/file30191/ref435.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] stat module in C
Christian Heimes added the comment: AP has started to review my patch. I'm not yet sure how we should handle constants and functions when the platform doesn't provide them. For example Windows doesn't have any S_IS*() function like macros and doesn't provide a S_IFBLK constant. We have three possibilities here: 1) omit the constant / function (breaks b/w compatibility) 2) add constant with a value of 0 / function that returns false (may break b/w compatibility) 3) default to current value from Lib/stat.py I'm against 1) because it breaks backwards compatibility and makes the module harder to use. I like to follow 3) for all S_I*, SF_* and UF_* macros and functions that are currently provided by the stat module and 2) for new constants and functions such as S_ISDOOR(). -- title: Add S_ISDOOR to the stat module - stat module in C ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Eli Bendersky added the comment: I don't see docs in the patch, but perhaps that should be a separate patch to keep reviewing easier. Also, Ethan, number the patch files in some way (like pep-435.1.patch, pep-435.N.patch) as they go through rounds of reviews. -- assignee: docs@python - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5901] missing meta-info in documentation pdf
A.M. Kuchling added the comment: This seems to be fixed now. I downloaded python-3.3.1-docs-pdf-letter.tar.bz2 and ran pdfinfo on using.pdf: Title: Python Setup and Usage Subject: Keywords: Author: Guido van Rossum, Fred L. Drake, Jr., editor Creator:LaTeX with hyperref package Producer: pdfTeX-1.40.10 CreationDate: Fri May 10 09:42:17 2013 ModDate:Fri May 10 09:42:17 2013 Tagged: no Pages: 65 Encrypted: no Page size: 612 x 792 pts (letter) File size: 432316 bytes Optimized: no PDF version:1.4 We could fill in Subject and Keywords, but the basic fields of Title and Author seem to be present. (Do we need to change author to 'Python Development Group' or 'PSF'?) -- nosy: +akuchling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5901 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17941] namedtuple should support fully qualified name for more portable pickling
Eli Bendersky added the comment: A question that came up while reviewing the new enum code: module or module_name for this extra argument? The former is shorter, but the latter is more correct in a way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17941] namedtuple should support fully qualified name for more portable pickling
Guido van Rossum added the comment: Module, please. The class attribute is also called __module__ after all. On Friday, May 10, 2013, Eli Bendersky wrote: Eli Bendersky added the comment: A question that came up while reviewing the new enum code: module or module_name for this extra argument? The former is shorter, but the latter is more correct in a way. -- ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue17941 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Eli Bendersky added the comment: OK, I sent another batch of reviews through the code review system - Ethan you should've gotten an email about it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17941] namedtuple should support fully qualified name for more portable pickling
Eli Bendersky added the comment: On Fri, May 10, 2013 at 7:02 AM, Guido van Rossum rep...@bugs.python.orgwrote: Guido van Rossum added the comment: Module, please. The class attribute is also called __module__ after all. Makes sense. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Eli Bendersky added the comment: Regarding module vs. module_name for the extra param in the functional API, Guido rightly points out in issue 17941 that __module__ is the class attribute, so module is a consistent choice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14596] struct.unpack memory leak
Meador Inge added the comment: Serhiy Storchaka added the comment: So what about more compact Struct object? I already implemented the count optimization as a part of my patch for implementing PEP 3188 in issue3132. I need to rebaseline the patch. It has gotten stale. Hopefully there is still interest in the PEP 3188 work and I can get that patch pushed through. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Ethan Furman added the comment: Incorporated comments. -- Added file: http://bugs.python.org/file30195/pep-0435_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Changes by Ethan Furman et...@stoneleaf.us: -- hgrepos: -189 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Changes by Zachary Ware zachary.w...@gmail.com: -- nosy: +zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1045893] warning '_POSIX_C_SOURCE redefined' when include Python.h
Jonathan Wakely added the comment: Insisting on including Python.h first is just broken. GNU libc's /usr/include/features.h will override it anyway when _GNU_SOURCE is defined: # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE200809L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 700 So if you define _GNU_SOURCE ( which happens automatically when using G++) the annoying defines in pyconfig.h are overridden anyway, so why not just only define them if not already defined? Either you include Python.h first and its settings get ignored by glibc, or you don't include it first and you get annoying warnings. -- nosy: +Jonathan.Wakely ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1045893 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Roundup Robot added the comment: New changeset d331e14cae42 by Guido van Rossum in branch 'default': #17927: Keep frame from referencing cell-ified arguments. http://hg.python.org/cpython/rev/d331e14cae42 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Guido van Rossum added the comment: Ok, the deed is done. Thanks for your review, Benjamin! I've reassigned it to you so you can fix up the test if you want to. What would you think of a backport to 3.3? -- assignee: gvanrossum - benjamin.peterson resolution: - fixed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17883] Fix buildbot testing of Tkinter
Zachary Ware added the comment: Thanks for your response, Martin. Martin v. Löwis wrote: Zach: Temporarily committing changes to test specific buildbot issues is fine I suppose it would also be beneficial to get some output from the other bots which are *not* failing, to have something to compare with. In that case, here's a (very) temporary patch we can try for a round of builds. asking the slave operator for direct access to the machine may also work. Trent, what's your policy on letting non-committers play around in your machines? :) Alternately, do you know of anything about that machine that could be causing the failures? -- nosy: +trent Added file: http://bugs.python.org/file30196/issue17883-tmp-test.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17883 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17944] Refactor test_zipfile
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file30197/test_zipfile_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17949] operator documentation mixup
New submission from Martijn Pieters: Rev 83684 (http://hg.python.org/cpython/rev/5885c02120f0) managed to move the `attrgetter()` `versionadded` and `versionchanged` notes down to the `itemgetter()` documentation instead, by moving the `itemgetter()` signature *up* above these lines. Now the docs claim `itemgetter()` gained support for dotted attributes in version 2.6, which makes no sense, and there is another set of added and changed notes lower down in the same section. This patch puts the `itemgetter()` signature back in the correct location. -- assignee: docs@python components: Documentation files: operator_documentation_fix.patch keywords: patch messages: 188846 nosy: docs@python, mjpieters priority: normal severity: normal status: open title: operator documentation mixup versions: Python 2.7 Added file: http://bugs.python.org/file30198/operator_documentation_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Antoine: precisely. Serhiy: sure. The times are now in msec per loop. I did three subsequent runs, so the second and third tuple are cache-warm. Without assert: (89,88), (87,87), (89,86) Without block : (79,78), (78,78), (79,78) And in a second run: Without assert: (87,88), (87,88), (92,87) Without block : (111,91), (78,85), (79,79) This means that, again, removing the “optimised” code speeds up operations (on this particular slow architecture. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16523] attrgetter and itemgetter signatures in docs need cleanup
Martijn Pieters added the comment: The 2.7 patch shifted the `itemgetter()` signature to above the `attrgetter()` change and new notes. New patch to fix that in issue #17949: http://bugs.python.org/issue17949 -- nosy: +mjpieters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16523 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17949] operator documentation mixup
Roundup Robot added the comment: New changeset 9c93a631e95a by Ezio Melotti in branch '2.7': #17949: fix merge glitch in itemgetter signature. Patch by Martijn Pieters. http://hg.python.org/cpython/rev/9c93a631e95a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17949] operator documentation mixup
Ezio Melotti added the comment: Fixed, thanks for the report and the patch! -- assignee: docs@python - ezio.melotti nosy: +ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue995907] memory leak with threads and enhancement of the timer class
Charles-François Natali added the comment:
I'm attaching a proof of concept code for a ScheduledExecutor
interface, and a ScheduledThreadPoolExecutor implementation
(unfortunately I can't upload it as a mercurial diff for now).
Here's what the API looks like:
from concurrent.futures import ScheduledThreadPoolExecutor
import time
def say(text):
print({}: {}.format(time.ctime(), text))
with ScheduledThreadPoolExecutor(5) as p:
p.schedule(1, say, 'hello 1')
f = p.schedule_fixed_rate(0, 2, say, 'hello 2')
p.schedule_fixed_delay(0, 3, say, 'hello 3')
time.sleep(6)
say(cancelling: %s % f)
f.cancel()
time.sleep(10)
say(shutting down)
schedule() is for one-shot, schedule_fixed_rate() for fixed rate
scheduling (i.e. there will be no drift due to the task execution
time), and schedule_fixed_delay() is for fixed delay (i.e. there will
always be a fixed amount of time between two invokations).
Random notes:
- the scheduling is handled by a new SchedQueue in the queue module:
sched would have been useful, but actually it can't be used here: it
stops as soon as the queue is empty, when it calls the wait function
it won't wake up if a new task is enqueued, etc. Also, I guess such a
queue could be useful in general.
- I had to create a DelayedFuture subclass, which is returned by
schedule_XXX methods. The main differences with raw Future are that it
has a scheduled time and period attributes, and supports
reinitialization (a future can only be run once). It can be cancelled,
and also supports result/exception retrieval.
- I don't know if a process-based counterpart
(ScheduledProcessPoolExecutor) is really useful. I didn't look at it
for now.
--
Added file: http://bugs.python.org/file30199/scheduled.diff
Added file: http://bugs.python.org/file30200/test.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue995907
___diff -ur cpython.orig/Lib/concurrent/futures/_base.py
cpython-b3e1be1493a5/Lib/concurrent/futures/_base.py
--- cpython.orig/Lib/concurrent/futures/_base.py2013-05-07
08:21:21.0 +
+++ cpython-b3e1be1493a5/Lib/concurrent/futures/_base.py2013-05-10
16:35:16.0 +
@@ -6,7 +6,10 @@
import collections
import logging
import threading
-import time
+try:
+from time import monotonic as time
+except ImportError:
+from time import time
FIRST_COMPLETED = 'FIRST_COMPLETED'
FIRST_EXCEPTION = 'FIRST_EXCEPTION'
@@ -188,7 +191,7 @@
before the given timeout.
if timeout is not None:
-end_time = timeout + time.time()
+end_time = timeout + time()
with _AcquireFutures(fs):
finished = set(
@@ -204,7 +207,7 @@
if timeout is None:
wait_timeout = None
else:
-wait_timeout = end_time - time.time()
+wait_timeout = end_time - time()
if wait_timeout 0:
raise TimeoutError(
'%d (of %d) futures unfinished' % (
@@ -390,11 +393,11 @@
elif self._state == FINISHED:
return self.__get_result()
-self._condition.wait(timeout)
+gotit = self._condition.wait(timeout)
if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED]:
raise CancelledError()
-elif self._state == FINISHED:
+elif gotit:
return self.__get_result()
else:
raise TimeoutError()
@@ -423,11 +426,11 @@
elif self._state == FINISHED:
return self._exception
-self._condition.wait(timeout)
+gotit = self._condition.wait(timeout)
if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED]:
raise CancelledError()
-elif self._state == FINISHED:
+elif gotit:
return self._exception
else:
raise TimeoutError()
@@ -499,6 +502,39 @@
self._condition.notify_all()
self._invoke_callbacks()
+
+class DelayedFuture(Future):
+A future whose execution can be delayed, and periodic.
+
+def __init__(self, sched_time, period=0, delay=0):
+super().__init__()
+self._sched_time = sched_time
+if period 0:
+# step 0 = fixed rate
+self._step = period
+elif delay 0:
+# step 0 = fixed delay
+self._step = -delay
+else:
+# step == 0 = one-shot
+self._step = 0
+
+def is_periodic(self):
+return self._step != 0
+
+def get_sched_time(self):
+return self._sched_time
+
+def rearm(self):
+Re-arm the future, and update its scheduled execution time.
+with self._condition:
+if self._step 0:
+self._sched_time += self._step
+
[issue17904] bytes should be listed as built-in function for 2.7
Ezio Melotti added the comment: Here's a patch. Do you think it should be added under the string signature too? It will make linking easier, but it might be more confusing for users. -- keywords: +patch nosy: +chris.jerdonek, ezio.melotti stage: needs patch - patch review type: behavior - enhancement Added file: http://bugs.python.org/file30201/issue17904.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17927] Argument copied into cell still referenced by frame
Martin Morrison added the comment: Our usage of Python would certainly benefit from the backport. We are embedding Python 3.3 in a system with requirements that lead us to disable the gc in most cases, so cycles are an obvious problem for us. Cycles created inadvertently, such as this, are the biggest problem. We would probably backport the fix anyway, but would prefer not to carry patches and instead pick up fixes via 3.3.x releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17468] Generator memory leak
Antoine Pitrou added the comment: The issue17807 patch has now been committed and should solve this issue. I would like to encourage anyone to test this change, as it is quite a significant departure from the previous semantics: http://mail.python.org/pipermail/python-dev/2013-May/126102.html -- assignee: docs@python - components: +Interpreter Core -Documentation resolution: - duplicate status: open - closed superseder: - Generator cleanup without tp_del ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17907] Deprecate imp.new_module() in favour of types.ModuleType
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17920] Documentation: complete ordering should be total ordering
Ezio Melotti added the comment: Raymond, since this has been merged to default too in e163c13b941c, can the issue be closed or is there something else left to do? -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17923] test glob with trailing slash fail
Changes by Ezio Melotti ezio.melo...@gmail.com: -- components: +Library (Lib) nosy: +ezio.melotti stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17923 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17947] Code, test, and doc review for PEP-0435 Enum
Ethan Furman added the comment: More adjustments due to review. -- Added file: http://bugs.python.org/file30202/pep-0435_3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17940] extra code in argparse.py
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +bethard stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17940 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17906] JSON should accept lone surrogates
Bob Ippolito added the comment: The patch that I wrote for simplejson is here (it differs a bit from serhiy's patch): https://github.com/simplejson/simplejson/commit/35816bfe2d0ddeb5ddcc68239683cbb35b7e3ff2 I discovered another bug along the way in the pure-Python scanstring, int(s, 16) will parse '0xNN' when json expects only strings of the form '' to work. I fixed that along with this issue by explicitly checking for x or X. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17906 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17948] HTTPS and sending a big file size hangs.
James O'Cull added the comment: We have more information on this bug here. It's SSL v2 related when pushing to IIS. http://stackoverflow.com/a/16486104/97964 Here's a paste from the StackOverflow answer: I found a few ways of dealing with this issue: To fix this server-side in IIS, download and install https://www.nartac.com/Products/IISCrypto/Default.aspx and click the BEAST button, or force SSL3.0 by disabling other protocols. If you don't have access to the IIS server, you can fix it by rolling back Python to version 2.7.2 or earlier. If you are adventurous, you can modify the mercurial source in sslutil.py, near the top, change the line sslsocket = ssl.wrap_socket(sock, keyfile, certfile, cert_reqs=cert_reqs, ca_certs=ca_certs) to from _ssl import PROTOCOL_SSLv3 sslsocket = ssl.wrap_socket(sock, keyfile, certfile, cert_reqs=cert_reqs, ca_certs=ca_certs, ssl_version=PROTOCOL_SSLv3) This will work around the problem and fix the push limit to mercurial behind IIS. If you are interested in why Python 2.7.3 broke this, look at http://bugs.python.org/issue13885 for the explanation (it is security-related). If you want to modify Python itself, in Modules/_ssl.c change the line SSL_CTX_set_options(self-ctx, SSL_OP_ALL ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS); back to how it was prior to 2.7.3: SSL_CTX_set_options(self-ctx, SSL_OP_ALL); Compile and reinstall python, etc. This adds more SSL compatibility at the expense of potential security risks, if I understand the OpenSSL docs correctly. -- nosy: +James.O'Cull ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
