ANN: lfm v2.1
Hi there, As a present for Christmas I announce here a new version of 'lfm'. Description: = Last File Manager is a simple but powerful file manager for the UNIX console. It's written in Python, using curses module. Licensed under GNU Public License version 3. Some of the features you could find in lfm: - console-based file manager for UNIX platforms - 1-pane or 2-pane view - tabs - bookmarks - history - vfs for compressed files - dialogs with entry completion - fast access to a shell - direct integration of find/grep, df and other tools - color files by extension - fast file viewer with text and binary modes - ...and many others Download it from: = http://www.terra.es/personal7/inigoserna/lfm or if it doesn't show last version (crap of ISP reverse proxy), try this low-bandwidth home server: http://inigo.katxi.org/devel/lfm Changes since last version: Version 2.1 (What do you want for Christimas?) - 2008/12/21: + Ctrl-H now show/hide dot files + Ctrl-Y display directories history + It's now posible to move the cursor in the non-active pane Consult the documentation for available keys and actions This behaviour is de/activated with Ctrl-W + added support for .7z compressed files + swapped F2 and F12 keys, now F2 rename files and F12 show file menu + new key shortcuts in dialogs. Read docs + speed up cursor movement + lots of code cleaning and refactoring + and fixed lot of bugs, some of them: - setup.py: change Iñigo for Inigo to avoid problems when installing - sorting by None doesn't crash anymore - MenuWin dialog crashed when title length was greater than length of entries to show Of course, all comments, suggestions, etc. are welcome. Best regards, Iñigo Serna -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Check file is
Hi Friends Is there any utility in python which will help me to read any pdf files? Regards Harish -- http://mail.python.org/mailman/listinfo/python-list
Re: Jarow-Winkler algorithm: Measuring similarity between strings
Thanks for the useful comments. On 20 Des, 01:38, John Machin sjmac...@lexicon.net wrote: On Dec 20, 10:02 am, Øyvind oyvin...@gmail.com wrote: Based on examples and formulas fromhttp://en.wikipedia.org/wiki/Jaro-Winkler. For another Python implementation, google febrl. Useful for measuring similarity between two strings. For example if you want to detect that the user did a typo. You mean like comparing the user's input word with some collection of valid words? You would need to be using something else as a quick-and- dirty filter ... Jaro-Winkler is relatively slow. Do you have any alternative suggestions? def jarow(s1,s2): Returns a number between 1 and 0, where 1 is the most similar example: print jarow(martha,marhta) m= jarow_m(s1,s2) t1 = jarow_t(s1,s2) t2 = jarow_t(s2,s1) t = float(t1)/float(t2) Huh? t1 and t2 are supposed to be counts of transpositions. So is t. So how come t is a ratio of t1 to t2?? BTW, suppose t2 is zero. Good point. There should be only one jarow_t. Also as the Wikipedia article says, it's not a metric. I.e. it doesn't satisfy dist(a, c) = dist(a, b) + dist(b, c). Its not a mathematical correct metric, but it is a useful heuristical metric. The above code is not symmetrical; jarow_m(s1, s2) does not necessarily equal jarow_m(s2, s1). The article talks about one m, not two of them. Hmm.. also a good point. I will make it count all the matches, not just the matches in s1. -- http://mail.python.org/mailman/listinfo/python-list
Today' Topic Managerial Values and ethos
Delhi Institute of Management Services
Dear friends,
We are extremely happy to welcome you to the world of Management... We
are in the process of preparing some 5 minutes revision Q A type
lessons for management students. They are in no way, a replacement for
the classroom lectures, textbooks or any other study guides. If you
wish to go through these lessons.
Please visit today's BLOGS:
What is Conflict
http://www.bookghar.com/What%20is%20Conflict.htm
Managerial Values and ethos
http://www.bookghar.com/Managerial%20Values%20and%20ethos.htm
We want you to suggest improvements or corrections if any, by
Email to Ms Sheetal Varma, (Senior HR Executive).
Email: dimsj...@gmail.com
If you are looking for a job or you want to change a job, please send
your resume to Ms Sheetal (Senior HR Executive). She will try to help
you to find a suitable job.
Email: dimsnau...@gmail.com
CAREER TRAINING
Join University Recognized Courses MBA {BM} MBA {HR}, MBA {MKT}, and
MBA {Fin}, MCA, BCA, MMC, BMC, B.com M.com M.Insurance, B.Fashion
For Career Development and Job Promotions.
CONTACT:
Delhi Institute of Management Services,
Study Centre of NMiMS UNIVERSITY, GURU JAMBHESHWAR UNIVERSITY, JAMIA
HAMDARD UNIVERSITY, ALL INDIA MANAGEMENT ASSOCIATION, PUNJAB TECHNICAL
UNIVERSITY, MUMBAI EDUCATION TRUST .
1108 Akashdeep Building, New Delhi 110001
TEL FAX: 23312187,
TEL: 23316475.
If you do not want to receive such mail in future. Please send mail
Email: bookghar2...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: mod_python resources
On Dec 20, 2:47 pm, Anjanesh Lekshminarayanan m...@anjanesh.net wrote: Same requirement here. But isnt there any mod_python for Python 3.0 ? Or do we need to build it from source ourselves ? I was hoping there would bemod_wsgibinaries for Python 3.0. At this stage it looks like there will not be a mod_python for Python 3.0. If you want the ability to run Python embedded in Apache like mod_python did, use a framework that can host on top of WSGI and host it on mod_wsgi instead. The version of mod_wsgi in subversion repository already supports Python 3.0. Graham -- http://mail.python.org/mailman/listinfo/python-list
Re: Check file is
AFAI can tell... (from a quick google search), there is only a commercial product that can read PDF... i.e. PageCatcher from ReportLabs.http://www.reportlab.org/devfaq.html (look at item 2.1.5) http://www.reportlab.org/devfaq.html BTW, an apparently, non platform-neutral way may be described here: http://www.daniweb.com/code/snippet618.html Alternatively, you could always use tools like pdf2txt to convert PDF into text, and then read it in, however, as you could guess, you completely miss out on the graphics (i.e. images), and the formatting aspects. On Sat, Dec 20, 2008 at 1:36 PM, Harish harish.bha...@gmail.com wrote: Hi Friends Is there any utility in python which will help me to read any pdf files? Regards Harish -- http://mail.python.org/mailman/listinfo/python-list -- regards, Banibrata http://www.linkedin.com/in/bdutta http://octapod.wordpress.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces, multiple assignments, and exec()
John O'Hagan resea...@johnohagan.com writes: I have a lot of repetitive assignments to make, within a generator, that use a function outside the generator: var1 = func(var1, args) var2 = func(var2, args) var3 = func(var3, args) etc... In each case the args are identical, but the first argument is a string of the name being assigned. It works fine but I'd like to reduce the clutter by doing the assignments in a loop. I've tried using exec(): for name in name_string_list: exec(name + ' = func(\' + name + '\, args)') but in the local namespace it doesn't understand func(), and if I give it globals() it doesn't understand the args, which come from within the generator. What's a good way to do this kind of thing? Your problem is describe in too vague a way to get good answers IMHO. Are var1, var2, ... globals or local to the generator? Can you give some sample code to show what doesn't work? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, Dec 20, 2008 at 12:30 AM, r rt8...@gmail.com wrote: Why could't we improve on what we had instead of making radical changes? Thats all i am asking. -- http://mail.python.org/mailman/listinfo/python-list Often times improving on what you have involves radical changes, especially if the goals of what you have change, or were not fully understood during their original implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Check file is
Harish wrote: Hi Friends Is there any utility in python which will help me to read any pdf files? Regards Harish Not sure, what you're after exactly, but I tried googling 'python read pdf' and found this, so maybe 'reportlab' is what you're looking for: Re: Reading PDF files #2 Dec 20th, 2006 To read and manage Portable Document Files you can use the open source ReportLab toolkit (written in Python) from: http://www.reportlab.org/rl_toolkit.html kind regards jorgen -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Steven D'Aprano wrote: I have no objection to the addition of the format() method (although I wonder whether it might have been better as a function). I actually learned about the String.format() method in Java a while after having read about str.format() in Python, and my first reaction was to recognise how stupid you'd have to be to make that a static method that ignores the string it's called on. :) I think '...'.format() makes sense given that we already have '...'.join(). Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: New Book: Programming in Python 3
On 20 Dec, 00:32, Colin J. Williams c...@ncf.ca wrote: Thomas Heller wrote: Mark Summerfield schrieb: Just a follow-up to say that the book has now been published in the U.S. It is now in stock at InformIT, and should reach other stores, e.g., Amazon, in a week or so. Also, the introduction, the first few pages of the first chapter, the whole of chapter 12 (regular expressions), and the index are now available for free download in a PDF from here: http://www.informit.com/store/product.aspx?isbn=0137129297 Question from a non-native english speaker: is this now valid english? One of Python's great strengths ^ and also teaches Python's functional programming features ^ The book's approach is wholly practical ^ Curious, Thomas No. Is this a quote from some advertising stuff or was it written by the author? Colin W. All three fragments are taken from the book's Introduction, and all are correct English---both U.S. and British as it happens. (You can read them in context by downloading the sample pages PDF.) See: http://en.wikipedia.org/wiki/Apostrophe You'll also find a few instances of possessive plurals (s') in later chapters:-) The whole book was proof read by a professional (American) proof reader---in addition to the several technical reviewers who read it. There is one point of (minor) controversy in my English usage---I make my writing gender-neutral by using singular they. This is valid in both U.S. and British English but doesn't seem to be very common, but I much prefer it to all the alternatives I've seen. http://en.wikipedia.org/wiki/Singular_they With two dozen postings on my use of English I'm now rather nervous about the feeback I'll get on my Python 3! PS Although Amazon.com still says the publication date is the 27th, they now expect to have it in stock on Monday (the 22nd). -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Fri, 19 Dec 2008 17:12:00 -0800, r wrote: Marc, Why move away from a concise and widely accepted way of sting formatting, just to supposedly make it a little easier for n00bs? (which i disagree this is easier) In turn, creating more syntactical clutter. (%s %f %d) is all you need to remember. If people can't understand that, i fear for the future of Humans as a species! Yeah, doomsday is near. Curly brackets and a number instead of a percent sign followed by an 's' is a sure sign of the end… You're a funny little troll, Sir. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
check whether a JPG is completed?
there are some pics(most of them are JPGs) on my disk, but some are not completed, that is to say, if I view it in irfanview, the bottom is displayed as a gray block. so I want to check where they are completed. but how to do that in python? (No, I am not saying how to tell the fileszie when I download a file from internet) thanx -- http://mail.python.org/mailman/listinfo/python-list
Re: Jarow-Winkler algorithm: Measuring similarity between strings
On Dec 20, 7:07 pm, Øyvind oyvin...@gmail.com wrote: Thanks for the useful comments. On 20 Des, 01:38, John Machin sjmac...@lexicon.net wrote: On Dec 20, 10:02 am, Øyvind oyvin...@gmail.com wrote: Based on examples and formulas fromhttp://en.wikipedia.org/wiki/Jaro-Winkler. For another Python implementation, google febrl. Useful for measuring similarity between two strings. For example if you want to detect that the user did a typo. You mean like comparing the user's input word with some collection of valid words? You would need to be using something else as a quick-and- dirty filter ... Jaro-Winkler is relatively slow. Do you have any alternative suggestions? Use a Levenshtein or Damerau edit distance. The latter handles adjacent transpositions (...AB...-...BA...) which covers well over 90% of the transposition errors I've ever seen. The remainder e.g. ...AXB...-...BXA... are given the same weight by Jaro-Winkler; this is IMHO silly. Read a little bit further than the CS101 level on Levenshtein edit distance and ignore any implementation which calculates all N*M cells of a dynamic programming matrix -- in the case where the objective is to calculate the distance except that once the distance is known to be over a threshold you don't care how big it is (you will reject a match if the distance is too big), then you only need to fill in the entries in a narrow band astride the trailing diagonal, and you can reliably give up if the current distance on the diagonal becomes too high. Ukkonen's the man in this field. It gets better. You can forget the matrix when the word lengths are less than the number of bits in your computer word (even 32 bits is enough for most words in most languages). The bit-parallel techniques include Damerau distance. This paper by Heikki Hyyrö is well worth reading, and refers to a whole lot of previous work, including Ukkonen's: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.2242 And you can forget about all the fancy techniques when the word lengths are so different that they can't be the same (e.g. Fu and Featherstonehaugh) -- or the shorter should perhaps be checked to see if it's a plausible abbreviation or contraction of the longer. Also as the Wikipedia article says, it's not a metric. I.e. it doesn't satisfy dist(a, c) = dist(a, b) + dist(b, c). Its not a mathematical correct metric, but it is a useful heuristical metric. Useful for what? IMHO: If it doesn't satisfy the symmetry condition and the triangle rule, it's just plain dodgy. J-W is dodgy and slow. Might as well use soundex. End of story. The above code is not symmetrical; jarow_m(s1, s2) does not necessarily equal jarow_m(s2, s1). The article talks about one m, not two of them. Hmm.. also a good point. I will make it count all the matches, not just the matches in s1. The whole Jaro definition is woolly ... what is a match when you have more than one occurrence of the same letter? Have a look at what the matches might be between MISSISSIPPI and a variant with an extra I in the middle e.g MISSISISIPPI. Cheers, John -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL on 3.x?
Méta-MCI (MVP) schrieb: Hi! This info is interesting for many people. IMO, it's a good idea to write the question in this newsgroup. Which only makes sense if the author of PIL reads it. Which he seems not to (or at least doesn't answer here, as he used to). Diez -- http://mail.python.org/mailman/listinfo/python-list
[OT] Re: IMAP: How to implement GMail-like threaded conversations view
snip/ Anything else is madness. And the fact the Outlook doesn't do proper referral fields just infuriates me. Sigh. I'm overjoyed about the opaque winmail.dat attachments I get. Which seem to appear randomly from the same sender sending the same stuff (like a meeting invitation) to me - depending on the moon cycle or something I presume... Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: encoding problem
On Fri, 19 Dec 2008 16:50:39 -0700, Joe Strout wrote: Marc 'BlackJack' Rintsch wrote: And does REALbasic really use byte strings plus an encoding!? You betcha! Works like a dream. IMHO a strange design decision. I get that you don't grok it, but I think that's because you haven't worked with it. RB added encoding data to its strings years ago, and changed the default string encoding to UTF-8 at about the same time, and life has been delightful since then. The only time you ever have to think about it is when you're importing a string from some unknown source (e.g. a socket), at which point you need to tell RB what encoding it is. From that point on, you can pass that string around, extract substrings, split it into words, concatenate it with other strings, etc., and it all Just Works (tm). Except that you don't know for sure what the output encoding will be, as it depends on the operations on the strings in the program flow. So to be sure you have to en- or recode at output too. And then it is the same as in Python -- decode when bytes enter the program and encode when (unicode) strings leave the program. In comparison, Python requires a lot more thought on the part of the programmer to keep track of what's what (unless, as you point out, you convert everything into unicode strings as soon as you get them, but that can be a very expensive operation to do on, say, a 500MB UTF-8 text file). So it doesn't require more thought. Unless you complicate it yourself, but that is language independent. I would not do operations on 500 MiB text in any language if there is any way to break that down into smaller chunks. Slurping in large files doesn't scale very well. On my Eee-PC even a 500 MiB byte `str` is (too) expensive. But saying that having only one string type that knows it's Unicode, and another string type that hasn't the foggiest clue how to interpret its data as text, is somehow easier than every string knowing what it is and doing the right thing -- well, that's just silly. Sorry, I meant the implementation not the POV of the programmer, which seems to be quite the same. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Jarow-Winkler algorithm: Measuring similarity between strings
John Machin: This paper by Heikki Hyyrö is well worth reading, and refers to a whole lot of previous work, including Ukkonen's: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.2242 This is the site of the author: http://www.cs.uta.fi/~helmu/pubs/pubs.html There you can find updates too: http://www.cs.uta.fi/~helmu/pubs/cpm02.pdf But such researchers have to offer C/Pascal/Java code too of their papers. Implementing things from scratch every time is a waste of time. Probably using SSE instructions like ANDPS, ANDNPS, ORPS, XORPS allows to use bitwise operations on 128 bit, allowing to search for longer strings in the same time. And the GPU of graphic cards offers other possibilities: http://www.cbcb.umd.edu/software/cmatch/Cmatch.pdf Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: New Book: Programming in Python 3
Mark Summerfield wrote: [...] With two dozen postings on my use of English I'm now rather nervous about the feeback I'll get on my Python 3! There is no such thing as bad publicity. Quick, make a blog post about how there have been over twenty comments about your use of English (though don't forget to point out that it's correct). PS Although Amazon.com still says the publication date is the 27th, they now expect to have it in stock on Monday (the 22nd). Congratulations. I know what a relief it is to see a project of that size come to fruition! regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Stefan Behnel wrote: [...] I think '...'.format() makes sense given that we already have '...'.join(). Sure it does, but that doesn't stop a lot of people disliking str.join() regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote: On Dec 19, 10:04 pm, Steve Holden st...@holdenweb.com wrote: r wrote: Thanks Steven, We need a real Pepsi challenge here to show the insignificance of this change. I am not against change. But when we lose something as - compact- as %formating i'm going to want to see a damn good reason for it! Especially when this breaks code, and the French Connection is not good enough reason for me :) Christian said this was not going to be depreciated until 3.2, but that still puts the accepted way on the chopping block. If Python is so important to you it's a pity you haven't been playing any active role in its development. Do you expect the developers to be psychic? Steve, I just recently started to have an opinion about these things. The squeaky wheel get the grease, just allowing my voice be heard. It might seem that i am trashing Python dev, but that could not be further from the truth. Many great changes have been made in 3.0, i just feel strongly about C style formating. Why could't we improve on what we had instead of making radical changes? Thats all i am asking. I wasn't really a part of the decision-making process, but I anticipate that the developers' reply would be that the new scheme is much more adaptable, both to new data types (which can implement their own __format__ method) and to internationalization (because it's possible to alter word order in the format strings). Thanks for clarifying your approach, by the way, which isn't as unreasonable as it first seemed if you've only recently started using Python. You will find over time that the developers are right about these decisions much more than they are wrong, and you still have a couple of years to get used to it ;-) regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces, multiple assignments, and exec()
On Sat, 20 Dec 2008, Arnaud Delobelle wrote:
John O'Hagan resea...@johnohagan.com writes:
I have a lot of repetitive assignments to make, within a generator,
that use a function outside the generator:
var1 = func(var1, args)
var2 = func(var2, args)
var3 = func(var3, args)
etc...
In each case the args are identical, but the first argument is a
string of the name being assigned. It works fine but I'd like to
reduce the clutter by doing the assignments in a loop. I've tried
using exec():
for name in name_string_list:
exec(name + ' = func(\' + name + '\, args)')
but in the local namespace it doesn't understand func(), and if I give
it globals() it doesn't understand the args, which come from within
the generator.
What's a good way to do this kind of thing?
Your problem is describe in too vague a way to get good answers IMHO.
Are var1, var2, ... globals or local to the generator? Can you give
some sample code to show what doesn't work?
The vars are all local to the generator. This is what doesn't work (I have
omitted some functions called by the first function for brevity):
def iterizer(options_dict):
Convert controllable option values to generators
range_ctrls = ['length', 'variety', 'z_depth', 'z_variety']
numerical_ctrls = ['bank', 'bell', 'channel', 'click', 'chord', 'descend',
'divisor', 'forte', 'inv', 'large_scaly', 'metarandomt', 'metat',
'mirrors', 'part', 'pause', 'prime', 'program', 'rand', 'randomt',
'rotate', 'shuffle_phrase', 'split', 'small_scaly', 'tempo', 'translate',
'transpose', 'updown' , 'voice', 'volume']
list_ctrls = ['all_check', 'degrees', 'exclude', 'finelist', 'nondegrees',
'include', 'only', 'pattern', 'rhythm', 'z_test']
generators = {}
for item in options_dict.iteritems():
opt, value = item[0], item[1]
if value is not None:
if value[0] == C:
ctrl_opts = optparse(value[1:])
iterator = sequence_engine(ctrl_opts)
if opt in numerical_ctrls:
iterator = numerical_iter(iterator)
elif opt in range_ctrls:
iterator = range_iter(iterator)
else:
iterator = dummy_ctrl(value)
if opt not in list_ctrls:
iterator = numerical_iter(iterator)
generators[opt] = iterator
return generators
def inext(option, generators, options_dict):
Cycling version of next()
if generators.has_key(option):
try :
return generators[option].next()
except StopIteration:
minidict = {option:options_dict[option]}
minigens = iterizer(minidict)
generators.update(minigens)
return generators[option].next()
def sequence_engine(options):
Produce Sequence instances
engine_opts = ['length', 'variety', 'z_depth', 'z_variety', 'descend',
'divisor', 'forte', 'inv', 'large_scaly', 'mirrors', 'part', 'prime',
'rand', 'rotate', 'shuffle_phrase', 'split', 'small_scaly', 'translate',
'transpose', 'updown' , 'voice', 'all_check', 'degrees', 'exclude',
'finelist', 'nondegrees','include', 'only', 'pattern', 'z_test', 'cardinal']
engine_dict = {}
for item in engine_opts:
engine_dict[item] = options.__dict__[item]
generators = iterizer(engine_dict)
for name in engine_opts:
exec(name + ' = inext(\' + name +
'\ ,generators, engine_dict)')
etc..
The last loop fails to assign any names for the reasons described in the OP.
Regards,
John
--
http://mail.python.org/mailman/listinfo/python-list
WAGs on when django will use Python 3.0?
Will Django be primarily using Python 3.0 one year from now? Two years from now? Any WAGs? -- http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces, multiple assignments, and exec()
On Sat, 20 Dec 2008, Steven D'Aprano wrote:
On Sat, 20 Dec 2008 02:53:16 +, MRAB wrote:
If you're sure you want to use the current namespace then:
for name in namelist:
vars()[name] = func(name, args)
Doesn't work inside a function:
def parrot():
... for name in ['A', 'B', 'C']:
... vars()[name] = ord(name)
... print vars()
... print A
...
parrot()
{'A': 65, 'C': 67, 'B': 66, 'name': 'C'}
Traceback (most recent call last):
File stdin, line 1, in module
File stdin, line 5, in parrot
NameError: global name 'A' is not defined
Historical note: I found an old post which stated that this used to work in a
function which invoked exec():
http://mail.python.org/pipermail/python-list/2000-September/050840.html
but I tried it in 2.5 and it doesn't any longer.
Regards,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces, multiple assignments, and exec()
On Sat, 20 Dec 2008, Terry Reedy wrote:
John O'Hagan wrote:
I have a lot of repetitive assignments to make, within a generator, that
use a function outside the generator:
var1 = func(var1, args)
var2 = func(var2, args)
var3 = func(var3, args)
etc...
In each case the args are identical, but the first argument is a string
of the name being assigned. It works fine but I'd like to reduce the
clutter by doing the assignments in a loop. I've tried using exec():
for name in name_string_list:
exec(name + ' = func(\' + name + '\, args)')
but in the local namespace it doesn't understand func(), and if I give it
globals() it doesn't understand the args, which come from within the
generator.
What's a good way to do this kind of thing?
Put everything in your own namespace
myvars={}
for name in namelist:
myvars[name]=func(name,args)
Likely I'm missing something, but don't I still have to do
var1 = myvars['var1']
var2 = myvars['var2']
var3 = myvars['var3']
...etc.
to make the assignments?
Regards,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: Namespaces, multiple assignments, and exec()
On Dec 19, 11:34 pm, John O'Hagan resea...@johnohagan.com wrote:
I have a lot of repetitive assignments to make, within a generator, that use a
function outside the generator:
var1 = func(var1, args)
var2 = func(var2, args)
var3 = func(var3, args)
etc...
In each case the args are identical, but the first argument is a string of the
name being assigned. It works fine but I'd like to reduce the clutter by
doing the assignments in a loop. I've tried using exec():
for name in name_string_list:
exec(name + ' = func(\' + name + '\, args)')
but in the local namespace it doesn't understand func(), and if I give it
globals() it doesn't understand the args, which come from within the
generator.
What's a good way to do this kind of thing?
Thanks,
John
Why don't you just use a dictionary?
d = {}
for name in name_string_list:
d[name] = func(name, args)
Luis
--
http://mail.python.org/mailman/listinfo/python-list
Re: WAGs on when django will use Python 3.0?
walterbyrd wrote: Will Django be primarily using Python 3.0 one year from now? Two years from now? I doubt they will drop 2.X support in the next two years. 3.0 will likely be supported fairly fully in the next year. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
teenflood - Free
teenflood . . . ***CLICK HERE http://club247.cn/teenflood * . . . . . . . . . . . . teenflood -- http://mail.python.org/mailman/listinfo/python-list
foot domme - Free
foot domme . . . ***CLICK HERE http://club247.cn/foot-domme * . . . . . . . . . . . . foot domme -- http://mail.python.org/mailman/listinfo/python-list
sapphic er - Free
sapphic er . . . ***CLICK HERE http://club247.cn/sapphic-er * . . . . . . . . . . . . sapphic er -- http://mail.python.org/mailman/listinfo/python-list
lesbo land - Free
lesbo land . . . ***CLICK HERE http://club247.cn/lesbo-land * . . . . . . . . . . . . lesbo land -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL on 3.x?
Hi! Fredrik Lundh (Pythonware ; the author of PIL (and ElementTree, and many other things)) had, in the past, often give answers. To me, like to others people. @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: check whether a JPG is completed?
Hi! Sometimes, PIL give an error. With try: Except:, you can get info. Sometimes, non error, but the Jpeg is not correct. Difficult, in this case, to get info. Therefore, the answer is: not in all cases. @-salutations -- Michel Claveau -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator slower than iterator?
Wow, thanks again =) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
Seriously cm_gui, you're a fool. Python is not slow. --JamesMills haha, getting hostile? python fans sure are a nasty crowd. Python is SLOW. when i have the time, i will elaborate on this. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python is slow
cm_gui wrote: Seriously cm_gui, you're a fool. Python is not slow. --JamesMills haha, getting hostile? python fans sure are a nasty crowd. Python is SLOW. Two lies in one posting! when i have the time, i will elaborate on this. Save your time, go somewhere else. Nobody here is interested. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: New Book: Programming in Python 3
I too will be interested in seeing the book. Nothing wrong with Lout -- and you can choose what suits you best, of course -- but just a couple of comments on the alternative. On Dec 19, 5:21 pm, Mark Summerfield l...@qtrac.plus.com wrote: : - I can't draw but I can tell lout to draw for me and that works well for my simple needs There are very competent and widely used packages to draw in LaTeX. Two are PSTricks and TikZ (you can google them each). - embedding graphics (e.g., screenshots) is easy (just convert to EPS) Similarly for LaTeX. - lout lets me specify Type1 fonts so I can easily use my own custom Venus font for code it is easy to embed it which makes publication easier Current distributions of LaTeX contain XeLaTeX which allows you to use any T1 font that you have (to use it in mathematical text you need to do more, but I don't expect that you have a lot of mathematical text in your book). - lots of books that use LaTeX have a certain sameness I don't like the computer modern fonts (IMO -- no offence intended) There are many alternative document styles and fonts available. - after more than a decade of using lout I can pretty well get it to do anything everything I want (but I don't claim to be an expert user) Fair enough. Jim -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 12:43 pm, excord80 excor...@gmail.com wrote:
Also, I like having only *one* special symbol (`%') to worry
about in my strings instead of two (`{' and `}').
Actually the new way has, at least three special symbols: ( '{', '}' ,
'.') as well as the method name format so
%s=%s % (k, v) for k, v in params.items()
becomes:
{0}={1}.format((k, v) for k, v in params.items())
or something like that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Walter, Would you be kind enough to translate this code to the new syntax? s = 'python' n = 12 f = 1.3 '%s %05d %0.2f' %(s,n,f) 'python 00012 1.33' i want to see how casting is handled. Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 19, 10:55 am, bearophileh...@lycos.com wrote: Regarding the speed of Python3 programs, they will go faster The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. http://docs.python.org/dev/3.0/whatsnew/3.0.html (Ruby programs are often slower than Python ones (because Ruby is a little higher level than Python) As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I am no expert on the subject, I am just going by stuff I have read on web. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 4:34 pm, r rt8...@gmail.com wrote: Walter, Would you be kind enough to translate this code to the new syntax? I am sorry, but I just don't know the new syntax well enough. I am not sure if the examples that I have posted, so far, are correct. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Thanks, i understand. Maybe some of the pro new syntax guys will show a translation -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd wrote:
On Dec 19, 12:43 pm, excord80 excor...@gmail.com wrote:
Also, I like having only *one* special symbol (`%') to worry
about in my strings instead of two (`{' and `}').
Actually the new way has, at least three special symbols: ( '{', '}' ,
'.') as well as the method name format so
%s=%s % (k, v) for k, v in params.items()
becomes:
{0}={1}.format((k, v) for k, v in params.items())
or something like that.
{0}={1}.format(k, v) for k, v in params.items()
or:
{0}={1}.format(*i) for i in params.items()
--
http://mail.python.org/mailman/listinfo/python-list
ANN: lfm v2.1
Hi there, As a present for Christmas I announce here a new version of 'lfm'. Description: = Last File Manager is a simple but powerful file manager for the UNIX console. It's written in Python, using curses module. Licensed under GNU Public License version 3. Some of the features you could find in lfm: - console-based file manager for UNIX platforms - 1-pane or 2-pane view - tabs - bookmarks - history - vfs for compressed files - dialogs with entry completion - fast access to a shell - direct integration of find/grep, df and other tools - color files by extension - fast file viewer with text and binary modes - ...and many others Download it from: = http://www.terra.es/personal7/inigoserna/lfm or if it doesn't show last version (crap of ISP reverse proxy), try this low-bandwidth home server: http://inigo.katxi.org/devel/lfm Changes since last version: Version 2.1 (What do you want for Christimas?) - 2008/12/21: + Ctrl-H now show/hide dot files + Ctrl-Y display directories history + It's now posible to move the cursor in the non-active pane Consult the documentation for available keys and actions This behaviour is de/activated with Ctrl-W + added support for .7z compressed files + swapped F2 and F12 keys, now F2 rename files and F12 show file menu + new key shortcuts in dialogs. Read docs + speed up cursor movement + lots of code cleaning and refactoring + and fixed lot of bugs, some of them: - setup.py: change Iñigo for Inigo to avoid problems when installing - sorting by None doesn't crash anymore - MenuWin dialog crashed when title length was greater than length of entries to show Of course, all comments, suggestions, etc. are welcome. Best regards, Iñigo Serna -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Just to be on record, i am OK with adding a new way to do this as long as the old C style str format does not ever go away. I don't like 20 ways to do the same thing, but i really like the compact way of %formating now. My complaint is the deprecation of %formating. Maybe i'll use the new syntax to print a tuple or two, but that is the only use i have for it ;). Slowing down Python even more than it is, is suicide. Sure high level languages are slower than there complied brethren, but a line has to be drawn in the sand somewhere. As CPU speeds increase so does the complexity's of modern software. GUI toolkits hog more resources as they need eye pleasing glass effects. You can't just blindly Parrot off.. well CPU's get faster every year. Python must stay fast, and simplistic(but not too simplistic), to compete with other high level languages. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
In article b58f588a-e8db-41df-a488-f7df62d56...@w39g2000prb.googlegroups.com, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 5:27 pm, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. You are exactly right Walter. I have not even considered this angle yet. Most of the complaints i hear are the redundant use of self. Which I lamented about but have become accustom(brainwashed) to it. I would remove this if it where up to me. I also hear a lot of complaints about speed. But never once in my life a problem with new users and string formatting. hmmm... food for thought -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote:
Walter,
Would you be kind enough to translate this code to the new syntax?
s = 'python'
n = 12
f = 1.3
'%s %05d %0.2f' %(s,n,f)
'python 00012 1.33'
i want to see how casting is handled. Thanks
'{0} {1:05} {2:.2}'.format(s, n, f)
'python 00012 1.3'
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: In article b58f588a-e8db-41df-a488-f7df62d56...@w39g2000prb.googlegroups.com, walterbyrd walterb...@iname.com wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. Would your life end if '\' was not a continuation char? Mine would not because i don't write my code to need it. Python has real warts that need fixing, and thats really hard for me to say, because i am such a fanboy of Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: best way to code
On Dec 19, 2:35 pm, Peter Otten __pete...@web.de wrote:
eric wrote:
hi,
I need to find a good design pattern to instanciate, and add
specific code all in one. Let me explain it :
I need to define some code, better be in a class, something like
class LinkA(object):
def mystuff(self):
do something different
class LinkB(object):
def mystuff(self):
do something different again
AND I need an instance of this class
{ stuff A: LinkA()
stuff B: LinkB()
}
This kind of code would be fine, I mean, the result effect in memory
is fine for me.
But I don't like the way I have to
1/ give a useless name to LinkA, linkB (there can be hundreds of names
like that)
2/ I have to write it down two times (and that's one time too much)
any ideas ?
something like
[
new object():
def mystuff(self):
do something
,
new object():
def mystuff(self):
do something else
]
would be really perfect (but I know it does not work, or at least, I
don't know how to make it work)
In fact, I would like to define a class, and an instance in a single
statement
class Register:
... def __init__(self):
... self.items = []
... def __call__(self, method):
... class Link(object):
... mystuff = method
... self.items.append(Link())
... register = Register()
@register
... def mystuff(self): print first
... @register
... def mystuff(self): print second
... for item in register.items:
... item.mystuff()
...
first
second
Peter
Wow, loved this solution. Never thought about using decorators to
solve this kinda problems.
nice
-
Nicolás Miyasato (miya)
http://myPythonNotes.wordpress.com
http://nmiyasato.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Thanks MRAB, except the float is not 2 decimal places, but its there Come on... They did this for the interpreter not us. It's easer to parse this string with positional arguments and a dict of format descriptions. Come on pydev, at least be honest about it! -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
walterbyrd: As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I have already answered regarding Python3 in this thread. Regarding Ruby you are right, in computer science there are lot of ways to speed up things. So it may be quite possible for Ruby to become faster than CPython. For example this may speed up the PythonVM some: Optimizing direct threaded code by selective inlining: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829rep=rep1type=pdf Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess.Popen inheriting
On Dec 18, 7:21 pm, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: En Thu, 18 Dec 2008 19:46:45 -0200, Aaron Brady castiro...@gmail.com escribió: snip On Windows, file handles are the real OS stuff, the true reference to an open file. File descriptors are not, they exist only to please the C runtime library. Programs not written in C (directly, or indirectly like Python) don't care at all about file descriptors. And in case one actually cares, there is _open_osfhandle in the C RTL (available as msvcrt.open_osfhandle from Python). A subprocess may inherit handles from its parent [there are two filters: the parameter bInheritHandles in the CreateProcess call provides global control, and individual handles can be made inheritable or not, before creating the new subprocess]. Anonymous pipes are good to replace stdin/stdout/stderr, because there is no need to explicitely communicate the handle value to the subprocess: one just replaces the corresponding handle with the desired pipe, and the subprocess might not even notice it. In case this is not enough, one might pass the handle (as a number) in the command line, but probably a named pipe would be better. As this is not transparent for the child process, one must explicitely code such things. Will it take calling 'CreatePipe' from ctypes directly if on Windows? Or can 'os.pipe' be made to abstract that? If Windows can't inherit descriptors, 'os.pipe' should return handles, and 'os.read' co. should accept them. I think the best way would be to modify os.pipe so it returns inheritable pipes, as it should have been from the beginning. It is a fairly large patch. Not at all, you have already posted most of it. I have marginally tested the patch on a custom build. It works, but there is a catch. The descriptor can't be passed directly to the child on the command line. You need to call 'msvcrt.get_osfhandle' on the descriptor, pass the result, then call 'msvcrt.open_osfhandle' in the child. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
In article 6b4176c3-49ce-4e7c-bced-07d8d19bc...@s20g2000yqh.googlegroups.com, r rt8...@gmail.com wrote: You can't just blindly Parrot off.. well CPU's get faster every year. Sure you can :-) There was a nice treatment of this on slashdot today (http://www.codinghorror.com/blog/archives/001198.html). The executive summary is I'm willing to accept that Python is (big handwave) 10x slower than C++, because *I'm* 10x faster writing in Python than I am in C++, and I cost more than my computer. Moore's laws says (small handwave) CPU speed doubles every 24 months. At that rate, and assuming I remember enough high-school algebra to solve a compound interest problem, hardware gets 10% faster every 3 months. If Python gets 10% slower every 10 years or so, it's ahead of the curve. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
r wrote:
Thanks MRAB,
except the float is not 2 decimal places, but its there
Oops!
'{0} {1:05} {2:.2f}'.format(s, n, f)
'python 00012 1.33'
'{0:s} {1:05d} {2:.2f}'.format(s, n, f)
'python 00012 1.33'
--
http://mail.python.org/mailman/listinfo/python-list
Re: PIL on 3.x?
Does anyone know if PIL will be ported to the 3.x branch? Have you considered e-mail to the author? No, I haven't because in my experience open source software authors prefer to keep discussion of their software on mailing lists, forums, etc, where others can benefit from the answers too. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 16:20:38 -0800, r wrote: On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. This makes no sense whatsoever. How does the line continuation character make any difference to backslashes inside a regex or a file path? Again, instead of whinging, what's your suggestion to fix it? Another suggestion, because your first: Would your life end if '\' was not a continuation char? is just stupid. The line continuation character is *irrelevant* to the problem of backslashes inside strings. For all the use it is, you might as well suggest changing the name None to Null. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 15:27:43 -0800, walterbyrd wrote: On Dec 19, 10:25 am, Michael Torrie torr...@gmail.com wrote: Personally the new string formatter is sorely needed in Python. Really? You know, it's funny, but when I read problems that people have with python, I don't remember seeing that. Loads of people complain about the white space issue. Some people complain about the speed. Lots of complaints about certain quirky behavior, but I have not come across any complaints about the string formatting. There are some things that some people whinge about, often just to hear the sound of their own voice (or the look of their own font, if you prefer). Whitespace and speed are two of those: they attract trolls and sooks. (That's not to say that there aren't real problems related to them. But it seems to me that the real problems are drowned out by the trolls.) Then there are things that people don't complain about, they just shrug and code a work-around. If % doesn't do what you want, do you cry about it, or do you code around it? I can't speak for others, but what I did was ask the question, discover that % was not powerful enough, and coded around it: http://mail.python.org/pipermail/python-list/2006-April/376641.html In fact, from what I have seen, many of the problems being fixed seem to be non-problems. I dunno, maybe it's just me. It's just you. Sheesh, I've never seen such a bunch of cry-babies sooking that their favourite language just got *more* power and flexibility. If functionality was being removed, I could understand the response, but this? It's just crazy. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
a small doubt
i wrote this code -- class Person(object): instancesCount = 0 def __init__(self, title=): Person.instancesCount += 1 self.id = tempst def testprint(self): print blah blah def __getattribute__(self, name): print in get attribute a = Person() a.testprint() print a.id - but i am getting this error in get attribute Traceback (most recent call last): File trapmethodcall1.py, line 15, in module a.testprint() TypeError: 'NoneType' object is not callable -- why is it so? __getattribute__ is called whenever an attribute or method is called, rt? or if i set __getattribute__ , i cannot have methods in class? actually my aim is to trap all method calls and keep a counter which is update whenever method called or returned. how should i go about it? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: On Sat, 20 Dec 2008 16:20:38 -0800, r wrote: On Dec 20, 6:05 pm, Roy Smith r...@panix.com wrote: I had an interesting experience with this recently. I was giving a co-worker quick python into. He's an experienced programer in various languages, but this was his first exposure to python. He got really hung up on the % syntax. By (bad) luck, he was trying to print a tuple (let's call it t), did format % t and was surprised at the result. It set him off on a but that's stupid, blah, blah, blah rant. I haven't absorbed the new syntax well enough to figure out if people will get hung up by this with the new syntax. It is stupid, more reason to fix the current problem instead creating a whole new one. Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. One more big complaint THE BACKSLASH PLAGUE. ever tried regexp?, or file paths?. All because that little backslash char is a line continuation character, maybe we should fix that. This makes no sense whatsoever. How does the line continuation character make any difference to backslashes inside a regex or a file path? Again, instead of whinging, what's your suggestion to fix it? Another suggestion, because your first: Would your life end if '\' was not a continuation char? is just stupid. The line continuation character is *irrelevant* to the problem of backslashes inside strings. For all the use it is, you might as well suggest changing the name None to Null. -- Steven i prefer None over Null myself, just another Pythonic beauty! ;) Steven, Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 16:01:58 -0800, r wrote: Just to be on record, i am OK with adding a new way to do this as long as the old C style str format does not ever go away. I don't like 20 ways to do the same thing, but i really like the compact way of %formating now. % formatting isn't compact unless you are only doing trivial substitutions. My complaint is the deprecation of %formating. % formatting hasn't been deprecated. All this Sturm und Drang over nothing. Maybe i'll use the new syntax to print a tuple or two, but that is the only use i have for it ;). Good for you. If your code is that trivial, then you're lucky. Slowing down Python even more than it is, is suicide. Oh noes, we're all gonna die!!! Just out of curiosity r, how old are you? 14? 15? You're remarkably mature for a 15 year old. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 17:54:09 -0800, r wrote: Would you like to elaborate on -why- escaped backslashes are needed in strings... i waiting??? If you can't escape backslashes in strings, how do you create a string containing a backslash? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: subprocess.Popen inheriting
On Dec 20, 7:06 pm, Aaron Brady castiro...@gmail.com wrote: On Dec 18, 7:21 pm, Gabriel Genellina gagsl-...@yahoo.com.ar wrote: En Thu, 18 Dec 2008 19:46:45 -0200, Aaron Brady castiro...@gmail.com escribió: snip Will it take calling 'CreatePipe' from ctypes directly if on Windows? Or can 'os.pipe' be made to abstract that? If Windows can't inherit descriptors, 'os.pipe' should return handles, and 'os.read' co. should accept them. I think the best way would be to modify os.pipe so it returns inheritable pipes, as it should have been from the beginning. It is a fairly large patch. Not at all, you have already posted most of it. I have marginally tested the patch on a custom build. It works, but there is a catch. The descriptor can't be passed directly to the child on the command line. You need to call 'msvcrt.get_osfhandle' on the descriptor, pass the result, then call 'msvcrt.open_osfhandle' in the child. Issue is at: http://bugs.python.org/issue4708 -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
bearophileh...@lycos.com wrote: walterbyrd: As I understand it, that may have been true at one time. But, Ruby 1.9 very significantly sped up the language. While Python has been made slower, Ruby has been made much faster. I have already answered regarding Python3 in this thread. Regarding Ruby you are right, in computer science there are lot of ways to speed up things. So it may be quite possible for Ruby to become faster than CPython. For example this may speed up the PythonVM some: Optimizing direct threaded code by selective inlining: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.8829rep=rep1type=pdf Interesting. The re module uses a form of bytecode. Not sure about the relative cost of the dispatch code, though. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Answering a question with a question, that leaves me with a question of my own?? Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Instead of being a blind fanboy and chastising everyone who dares to question pydev, Guido, or YOU... why don't you offer a good rebuttal? If i did not give a rats behind about Python i would not be here arguing with you. I would give up and require my packages ;). I prefer to import I believe Python has the best chance of surviving and becoming the king of high level languages, IF we don't muck it up! -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 17:55:35 -0800, Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' Errors should never pass silently, unless explicitly silenced. You have implicitly silenced the TypeError you get from not having enough arguments for the first format operation. That means that you will introduce ambiguity and bugs. %i %i %i %i % 5 % 3 %7 Here I have four slots and only three numbers. Which output did I expect? '%i 5 3 7' '5 %i 3 7' '5 3 %i 7' '5 3 7 %i' Or more likely, the three numbers is a mistake, there is supposed to be a fourth number there somewhere, only now instead of the error being caught immediately, it won't be discovered until much later. (BTW, if you want that behaviour, you should look at the string module.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL on 3.x?
On Dec 21, 12:32 pm, Daniel Fetchinson fetchin...@googlemail.com wrote: Does anyone know if PIL will be ported to the 3.x branch? Have you considered e-mail to the author? No, I haven't because in my experience open source software authors prefer to keep discussion of their software on mailing lists, forums, etc, where others can benefit from the answers too. True, so try a forum where the author has been active within the last week: http://mail.python.org/mailman/listinfo/image-sig -- http://mail.python.org/mailman/listinfo/python-list
Re: a small doubt
Piyush Anonymous wrote: i wrote this code -- class Person(object): instancesCount = 0 def __init__(self, title=): Person.instancesCount += 1 self.id http://self.id = tempst def testprint(self): print blah blah def __getattribute__(self, name): print in get attribute a = Person() a.testprint() print a.id http://a.id - but i am getting this error in get attribute Traceback (most recent call last): File trapmethodcall1.py, line 15, in module a.testprint() TypeError: 'NoneType' object is not callable -- why is it so? __getattribute__ is called whenever an attribute or method is called, rt? or if i set __getattribute__ , i cannot have methods in class? actually my aim is to trap all method calls and keep a counter which is update whenever method called or returned. how should i go about it? a.testprint causes __getattribute__ to be called. That method returns None. a.testprint() is therefore None(), hence the exception. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
Aaron Brady wrote: On Dec 20, 7:38 pm, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Go on. Take your time. I'll be waiting. Hi, not to take sides, but, there is a possibility. This behavior is currently legal: %i %%i % 0 % 1 '0 1' So, just extend it. (Unproduced.) %i %i % 0 % 1 '0 1' %r %i % (2, 3, 4) % 1 '(2, 3, 4) 1' %r %i % (2, 3, 4) '(2, 3, 4) %i' Which is quite clever and way ahead of its (posessive) time. A couple of problems: 1. How do you handle a literal '%'? If you just double up then you'll need to fix the string after all your substitutions. 2. What if a substitution introduces a '%'? I suppose a possible solution would be to introduce a special format string, including a literal, eg: f%r %i % (2, 3, 4) % 1 and then convert the result to a true string: print(str(f%r %i % (2, 3, 4) % 1)) (although print() would call __str__ anyway). The format string would track where the last substitution occurred. Hmm... I think I'll just learn the new method. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Sat, 20 Dec 2008 18:23:00 -0800, r wrote: Answering a question with a question, that leaves me with a question of my own?? Instead of just whinging, how about making a suggestion to fix it? Go on, sit down for an hour or ten and try to work out how a BINARY OPERATOR like % (that means it can only take TWO arguments) can deal with an arbitrary number of arguments, *without* having any special cases. Instead of being a blind fanboy and chastising everyone who dares to question pydev, Guido, or YOU... why don't you offer a good rebuttal? Because I thought it was obvious even you could see it. I'm disappointed to be proven wrong. A binary operator can only take two arguments: one on the left, and one on the right: 2 + 3 5 * 7 x == 2 %i % 7 The typical use-case for string formatting operations requires more than two arguments. Since % is a binary operator, it can only take two arguments. One of those arguments must be the template string, so the other argument has to wrap all the rest of the arguments into one object: The %s ate %d slices of %s. % (python, 7, spam) Python could have insisted that even single arguments be wrapped in a tuple: %s % (python,) At the cost of breaking backwards compatibility, that would solve the problem of treating tuples as a special case, but it seems wasteful and silly to be forced to write this: The answer is: %d % (5,) instead of The answer is: %d % 5 especially when people will invariably leave out the comma and then complain about the wart or bug that: The answer is: %d % (5) doesn't do what they expect. So tuples are treated as a special case: you only need to wrap a single argument in a tuple if that argument itself is a tuple: %s % ((0, 1, 2),) and everything else just works as you would expect. Again, at the cost of breaking backwards compatibility, Python could change the special case from tuples to something else, but what? And why bother? There will always be a special case, one way or another. Consequently, there is no way to fix the special casing of tuples without just shifting the problem. The problem is fundamental to the nature of binary operators: you can't fit an arbitrary number of arguments into two places (the left hand side, and the right hand side) of the % operator without having to special case something. The real solution is to stop trying to force arbitrary numbers of arguments into a single place, and instead use a function or method that takes multiple arguments. That's what the .format() method and the format() function do. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
linecache vs egg - reading line of a file in an egg
Does linecache work with source in Python eggs? If not, is it
contemplated that this is going to be fixed or is there something else
like linecache that currently works?
Right now, I think pdb and pydb (and probably other debuggers) are
broken when they try to trace into code that is part of an egg.
Here's what I tried recently:
Using this egg:
http://pypi.python.org/packages/2.5/t/tracer/tracer-0.1.0-py2.5.egg
I install that and look for the filename of one of the
functions. Here's a sample session:
import tracer
tracer
module 'tracer' from
'/usr/lib/python2.5/site-packages/tracer-0.1.0-py2.5.egg/tracer.pyc'
tracer.size
function size at 0xb7c39a74
tracer.size.func_code.co_filename
'build/bdist.linux-i686/egg/tracer.py'
tracer.size.func_code.co_firstlineno
216
To read the source for tracer.py, information from Accessing Package
Resources
(http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources)
suggests:
from pkg_resources import resource_string
print resource_string('tracer', 'tracer.py')
This gives me one long string which I can split and then index.
Note that I used tracer.py above, not
build/bdist.linux-8686/egg/tracer.py How do tracebacks and things that
read frame information deal with the discrepency?
Before reinventing the wheel and trying to extend linecache to do
something like the above, has someone already come up with a solution?
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Re: linecache vs egg - reading line of a file in an egg
R. Bernstein wrote: Does linecache work with source in Python eggs? If not, is it contemplated that this is going to be fixed or is there something else like linecache that currently works? linecache works with eggs and other zipped Python source, but it had to extend the API in order to do so. Some of the debuggers don't use the extended API. This will be fixed in the next 2.6.x bugfix release, but not in 2.5.3. http://bugs.python.org/issue4201 -- 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: linecache vs egg - reading line of a file in an egg
On Sat, Dec 20, 2008 at 7:18 PM, R. Bernstein ro...@panix.com wrote: Does linecache work with source in Python eggs? If not, is it contemplated that this is going to be fixed or is there something else like linecache that currently works? I believe it already does. FYI, eggs are just zip files with a certain file/directory structure. And linecache seems to handle reading from zipfile modules. Ergo, linecache can read source from eggs. Quoting from the linecache docs (http://docs.python.org/library/linecache.html), emphasis mine: linecache.getline(filename, lineno[, module_globals]) snip If a file named filename is not found, the function will ***look for it in the module search path, sys.path***, after first checking for a PEP 302 __loader__ in module_globals, in case the module was ***imported from a zipfile*** or other non-filesystem import source. Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On 20 Dez., 02:54, Steven D'Aprano st...@remove-this- cybersource.com.au wrote: Debated by who? The entire Python-using community? Every single Python programmer? Or just the small proportion of Python developers who are also core developers? If I'd asked people what they wanted, they would have asked for a better horse. Henry Ford -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python 3.0 string formatting - really necessary?
On Dec 20, 11:11 pm, walterbyrd walterb...@iname.com wrote: On Dec 20, 5:05 pm, Roy Smith r...@panix.com He got really hung up on the % syntax. I guess it's good to know that there is, at least, one person in the world doesn't like the % formatting. As least the move was not entirely pointless. But, you must admit, of all the things people complain about with Python, the % formatting is probably one of the least common complaints. Complaints about Python's speed seem much more common. Yet, 3.0 makes the speed worse, and fixes a non-problem. I can see where the new formatting might be helpful in some cases. But, I am not sure it's worth the cost. This all really comes down to the new python users. Yea, i said it. Not rabid fanboys like Steven and myself.(i can't speak for walter but i think he would agree) Are we going to make sure joe-blow python newbie likes the language. And doesn't get turned off and run over to ruby or whoever. Like it or not, without newusers python is doomed to the same fate as all the other great languages who had their 15 mins of fame. We must proactively seek out the wants of these new users and make sure python stays alive. But we also must not sell are pythonic souls in the process. It would be nice to get a vote together and see what does the average pythoneer want? What do they like, What do they dislike. What is the state of the Python Union? Does anybody know, Does anybody care? I think python is slipping away from it's dominate foothold on the world. Google's use of python may be the only thing holding this house of cards together. Ruby's hype is defiantly growing and unless we strive for greatness, python may fail. I think ruby may have their act together a little better than us right now. And since Ruby is such a hodge-podge of different languages, the __init__ hold is there for many. what does joe-python want??? -- http://mail.python.org/mailman/listinfo/python-list
Question: Evaluate an string variable's value to a variable
Just a quick question. For example I have class X pass Then I do x = X() x.name = 'Nazim Now my question is whether something like below is possible and how y = 'name' print x.y # How can x.y can be evaluated to x.name PS: In PHP this can be done by a $x-$y. I sure there is some way in Python also Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question: Evaluate an string variable's value to a variable
On Sat, Dec 20, 2008 at 10:49 PM, Mir Nazim mirna...@gmail.com wrote: Just a quick question. For example I have class X pass Then I do x = X() x.name = 'Nazim Now my question is whether something like below is possible and how y = 'name' print x.y # How can x.y can be evaluated to x.name print getattr(x, y) #== Nazim There are also analogous setattr() and delattr() functions. Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Question: Evaluate an string variable's value to a variable
On Dec 21, 11:56 am, Chris Rebert c...@rebertia.com wrote: On Sat, Dec 20, 2008 at 10:49 PM, Mir Nazim mirna...@gmail.com wrote: Just a quick question. For example I have class X pass Then I do x = X() x.name = 'Nazim Now my question is whether something like below is possible and how y = 'name' print x.y # How can x.y can be evaluated to x.name print getattr(x, y) #== Nazim There are also analogous setattr() and delattr() functions. Damn Right. These functions simply eluded my mind for well 15 minutes Thanks a lot Chris. Cheers, Chris -- Follow the path of the Iguana...http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
trapping all method calls in a class...
hi, i need to trap all method calls in a class in order to update a counter which is increased whenever a method is called and decreased whenever method returns. in order to that i am trying to write a decorator for all the methods. see the code here with error. --- http://codepad.org/2w7JVvDB any suggestions? any other better way of doing it? -- http://mail.python.org/mailman/listinfo/python-list
Re: trapping all method calls in a class...
On Sat, Dec 20, 2008 at 11:12 PM, Piyush Anonymous piyush.subscript...@gmail.com wrote: hi, i need to trap all method calls in a class in order to update a counter which is increased whenever a method is called and decreased whenever method returns. in order to that i am trying to write a decorator for all the methods. see the code here with error. --- http://codepad.org/2w7JVvDB any suggestions? any other better way of doing it? I call unnecessary use of metaclasses! Here's my (untested) attempt at a simpler class decorator approach: def decorate_meths(klass): attrs = klass.__dict__.items() for name, val in attrs: if callable(val): klass.__dict__[name] = decorate(val) def decorate(method): #should be called for every method call in the class def decorated(self, *args, **kwds): print 2 Inside __call__() returnval = method(self, *args,**kwds) print 3 After self.f(*args) return returnval return decorated #...@decorate_meths -- this syntax requires a later Python version class Person(object): def testprint(self,val): print blah blah Person = decorate_meths(Person) #rest of code after the class definition would be the same Sidenotes about your code: - `args` and `kwds` are the conventional names for the * and ** special arguments - the `methodname` variable was actually getting method objects, not strings, as its values; this was probably part of the bug in your program Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
[issue4701] range objects becomes hashable after attribute access
Hagen Fürstenau hfuerste...@gmx.net added the comment:
I don't believe there is any driving reason for them not to be hashable.
On the other hand, what is the use case for hashing objects whose
equality is defined as object identity?
Python 3.0 (r30:67503, Dec 4 2008, 06:47:38)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
range(10).__hash__
method-wrapper '__hash__' of range object at 0x7f2d61dbd210
{range(10), range(10)}
{range(0, 10), range(0, 10)}
I can see only confusion arising from that.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4701
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4704] Update pybench for python 3.0
New submission from Mark Dickinson dicki...@gmail.com: pybench needs to be updated for Python 3.0, in particular to remove use of cmp. Here's a patch, against the py3k branch. Questions (mainly for Marc-André Lemburg): 1. Should the version number be bumped for *all* tests, or just for those that have changed? Assuming all tests. 2. Presumably these changes should appear in 3.0.1, and should be backported to 2.x. Backport this to 2.6.2? Or just 2.7? 3. Should I update the sample output in the README file? I was going to just change the PYBENCH 2.0 line to PYBENCH 3.0, but that seems a little bit bogus without updating the rest. -- components: Demos and Tools files: pybench3.0.patch keywords: patch messages: 78090 nosy: lemburg, marketdickinson severity: normal status: open title: Update pybench for python 3.0 type: behavior versions: Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12405/pybench3.0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more refercenes to __cmp__
Mark Dickinson dicki...@gmail.com added the comment: Still to do: pybench needs updating to remove a cmp reference; since the changes required for pybench are a little bit more substantial than simple cmp replacement, I've broken this out into a separate issue: issue 4704. There are many uses of cmp still in the Demos directory. How much do we care? The documentation in Doc/extending/newtypes.rst needs updating. I can have a go at this, but Georg would almost certainly do a better job. -- dependencies: +Update pybench for python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more refercenes to __cmp__
Mark Dickinson dicki...@gmail.com added the comment: Should Py_CmpToRich (in object.c) disappear? It's currently used in longobject.c, but nowhere else as far as I can tell. It shouldn't be too hard to update longobject.c to remove the use. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4016] improve linecache: reuse tokenize.detect_encoding() and io.open()
STINNER Victor victor.stin...@haypocalc.com added the comment: I also think we should consider hard adding more modules that are loaded at startup time to py3k already huge list. My patch uses tokenize modules in setup.py bootstrap. But it doesn't affect Python classic usage python or python myscript.py. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4704] Update pybench for python 3.0
Marc-Andre Lemburg m...@egenix.com added the comment: On 2008-12-20 11:54, Mark Dickinson wrote: New submission from Mark Dickinson dicki...@gmail.com: pybench needs to be updated for Python 3.0, in particular to remove use of cmp. Here's a patch, against the py3k branch. Questions (mainly for Marc-André Lemburg): 1. Should the version number be bumped for *all* tests, or just for those that have changed? Assuming all tests. Just the tests that have been updated. Since there have been a number of small changes, I think it's time to also change the pybench version itself to 2.1 (not 3.0; that's reserved for more major changes). 2. Presumably these changes should appear in 3.0.1, and should be backported to 2.x. Backport this to 2.6.2? Or just 2.7? I don't think they should go into 3.0.1 - they are a new feature and not a bug fix. I'll leave that decision to the release manager. Please backport to 2.7 only. 3. Should I update the sample output in the README file? I was going to just change the PYBENCH 2.0 line to PYBENCH 3.0, but that seems a little bit bogus without updating the rest. Please run the suite and add the complete new output. Thanks, -- Marc-Andre Lemburg eGenix.com 2008-12-02: Released mxODBC.Connect 1.0.0 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more refercenes to __cmp__
Antoine Pitrou pit...@free.fr added the comment: It shouldn't be too hard to update longobject.c to remove the use. I'll do that one. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4565] io write() performance very slow
Antoine Pitrou pit...@free.fr added the comment: We can't solve this for 3.0.1, downgrading to critical. -- priority: release blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4561] Optimize new io library
Antoine Pitrou pit...@free.fr added the comment: We can't solve this for 3.0.1, downgrading to critical. -- priority: release blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4533] 3.0 file.read dreadfully slow
Antoine Pitrou pit...@free.fr added the comment: Since it is solved for 3.x and only needs to be bacported to 2.x (where the io module isn't the default), downgrading to critical. -- nosy: +pitrou priority: release blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4533 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3618] possible deadlock in IO library (Lib/io.py)
STINNER Victor victor.stin...@haypocalc.com added the comment: I hope that this issue will be fixed by io-c (io library rewritten in C language). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3106] speedup some comparisons
Antoine Pitrou pit...@free.fr added the comment: I committed the patch, which will also help #1717. Thanks! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3106 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more refercenes to __cmp__
Antoine Pitrou pit...@free.fr added the comment: It shouldn't be too hard to update longobject.c to remove the use. I'll do that one. Done in r67871, r67873. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1717 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4705] python3.0 -u: unbuffered stdout
New submission from STINNER Victor victor.stin...@haypocalc.com:
I like and I need an unbuffered standard output which was provided
by -u command line option (or PYTHONUNBUFFERED environment variable).
Current status of -u option in Python3: the option exists and change
the buffer size (disable buffering) of the stdin, stdout and stderr
file descriptors.
The problem is in initstdio() which creates files with buffering=-1
(default buffer) instead of buffering=0 (no buffering) or buffering=1
(line buffer). But open() enable line buffering of TextIOWrapper is
buffering=-1 and the raw file is a tty.
Example with py3k trunk:
$ ./python
import sys; sys.stdout.line_buffering
True
$ ./python |cat
import sys; sys.stdout.line_buffering
False
I would like line buffering when stdout is redirected to a pipe and -u
option is used. initstdio() have to be changed to choose buffering
option. So it's something like:
Index: Python/pythonrun.c
===
--- Python/pythonrun.c (révision 67870)
+++ Python/pythonrun.c (copie de travail)
@@ -810,7 +810,12 @@
#endif
}
else {
- if (!(std = PyFile_FromFd(fd, stdout, w, -1,
encoding,
+ int buffering;
+ if (1)
+ buffering = 1; /* line */
+ else
+ buffering = -1; /* default */
+ if (!(std = PyFile_FromFd(fd, stdout, w,
buffering, encoding,
errors, \n, 0))) {
goto error;
}
But if (1) have to be replaced if -u option is used :-) See
unbuffered variable of Modules/main.c.
--
messages: 78102
nosy: haypo
severity: normal
status: open
title: python3.0 -u: unbuffered stdout
versions: Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4705
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
STINNER Victor victor.stin...@haypocalc.com added the comment: naufraghi there are a lot of other places where EINTR naufraghi can cause and error. Can you write a list of these places? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1068268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4621] zipfile returns string but expects binary
STINNER Victor victor.stin...@haypocalc.com added the comment: In the ZIP file format, a filename is a byte string because we don't know the encoding. You can not guess the encoding because it's not stored in the ZIP file and it depends on the OS and the OS configuration. So t1.filename have to be a byte string and testzip.read() have to use bytes and not str. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4621 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4621] zipfile returns string but expects binary
STINNER Victor victor.stin...@haypocalc.com added the comment:
Oh, I see that zipfile.py uses the following code to choose the
filename encoding:
if flags 0x800:
# UTF-8 file names extension
filename = filename.decode('utf-8')
else:
# Historical ZIP filename encoding
filename = filename.decode('cp437')
So I'm maybe wrong: the encoding is known using a flag?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4621
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
