Genshi Compiler - Speed up your XML templates
Genshi Compiler 0.1.1 = I'm pleased to announce the first public release of Genshi Compiler! Project home: http://code.google.com/p/genshi-compiler/ Download here: http://code.google.com/p/genshi-compiler/downloads/ PyPI entry: http://pypi.python.org/pypi/genshi_compiler License: MIT software license Quality: Beta with good unit test coverage Genshi Compiler allows for rendering your Genshi template to Python source code. You can save the code as a Python module or compile it into a directly usable module object in memory. Just call the render function on the module with your template parameters to render the whole template or any of your template functions to render those fragments separately. According to my initial benchmarks the rendering speed is typically ~40x faster than doing the same using Genshi. There is a cost of this speedup, certainly. Some of Genshi's dynamic features are not available, most notably anything that depends on a template loader (xi:include), the XML element tree representation (py:match) or the token stream. If you've read this far, then I guess you want to see the tutorial: http://code.google.com/p/genshi-compiler/wiki/tutorial Regards, Viktor Ferenczi -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.16 06:06 PM, Tim Roberts wrote:
That's not true. Python allows tabs and spaces to be used in the
same source file, and even in the same source line.
You're right. TabError is only raised if the initial indentation is
inconsistent.
Not legal:
def spam():
tabprint('Wonderful spam!\n')
4 spacesprint('Bloody Vikings!')
Legal:
def eggs():
tabprint(
tabtab'Blech!\n',some spaces to align'Whaddya mean, blech?\n',
tabtab'I don\'t like spam!\n',spaces to align'...'
tabtab)
I'm not saying it's wise
Why not?
- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAwAGBQJOIo9DAAoJEPiOA0Bgp4/LOk4IALdGAOb3RXyunzWiDBn3vNpr
fIR7NdtFmNc1QtvxGm3RVV+wxUjVjeCv5bXuAr/RvYDWm+MRCCr+VbexV52sFAbm
2G1g4rWQnRPGXvDMTq1bjJKcYFnJga/LHBqnM0mWTAms6o4d+Pj5ZJ5uK5CsFcx+
oL7y3YuVrtw/hYRNqTaxhMMy3erayGt4h3sEDIaekNbaNwNFy/7M6+tFzPBNHupT
EZAjkVewIDEgRqd+hCZfuanuS4mX6P2pup1dgAUiMAjEXRJO4xQ1JmmuCVXiccE/
HyiPtiIsTorDGGtzkaSpBwc1RVeZEeluO+VeVt9pIGCupKnDcVty+1R1C1kmS2U=
=QXtI
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 9:09 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. With pure spaces, the text is laid out reliably for us both. And so I have my editor set to that behaviour. I have reluctantly come to do the same thing. There is a plethora of broken tools out there that don't handle tabs well, and consequently even though tabs for indentation are objectively better, I use spaces because it is less worse than the alternative. This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: Possible File iteration bug
Am 16.07.2011 05:42 schrieb Steven D'Aprano: You are right - it is a very big step for a very small functionality. Or you can look at the various recipes on the Internet for writing tail-like file viewers in Python, and solve the problem the boring old fashioned way. It is not only about this tail-like thing. There are other legitimate use cases for this. I once found myself in the need to have a growing list of data to be put into a database. This growth could, on one hand, need several minutes to complete, but on the other hand the data should be put into the database ASAP, but not too slow. So it was best to put on every DB call all data which were present into the DB and iterate over this until end of data. Then, I wished such a PauseIteration exception as well, but there was another, not-to-bad way to do it, so I did it this way (roughly, an iterable whose iterator was exhausted if currently no data were present and which had a separate method for signalling end of data. Roughly: while not source.done(): put_to_db(source) where put_to_db() iterates over source and issues the DB query with all data available to this point and then starting over. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT)) 3) Tabs create freedom in the form of user controlled indention. Indention width should be a choice of the reader NOT the author. We should never code in indention width; but that is EXACTLY what we are doing with spaces! No, the reader should be able to choose the indention width without ANY formatting required or without any collateral damage to the source code. Tabs offer freedom, spaces offer oppression. Why are you so obsessed with indentation length? Indentation length is just /one/ of the formatting choices that the author makes for the reader - and probably the /least/ significant one. There is for instance maximum line length, the number of empty lines, the author's method of alignment, spaces between the equals sign and so on. These are all much more dominant in the source code and none of this is left for the reader's disposition. Compare for instance variable= 11 anothervariable = 22 def whatever (prettylong = 1, alsoprettylong = 22, anotherone = 33): pass to variable=11 anothervariable=22 def whatever (prettylong=1, alsoprettylong=22, anotherone=33): pass Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 1:29 AM, Andrew Berg bahamutzero8...@gmail.com wrote:
You're right. TabError is only raised if the initial indentation is
inconsistent.
Not legal:
def spam():
tabprint('Wonderful spam!\n')
4 spacesprint('Bloody Vikings!')
Legal:
def eggs():
tabprint(
tabtab'Blech!\n',some spaces to align'Whaddya mean, blech?\n',
tabtab'I don\'t like spam!\n',spaces to align'...'
tabtab)
Even this is legal:
def eggs()
tabif spam:
tabspacesprint(Spam and eggs)
tabelse:
tabtabprint(Just eggs)
It's only when you're inconsistent about the added indent of a single
block that Python will complain.
--
http://mail.python.org/mailman/listinfo/python-list
a little parsing challenge ☺
2011-07-16
folks, this one will be interesting one.
the problem is to write a script that can check a dir of text files
(and all subdirs) and reports if a file has any mismatched matching
brackets.
• The files will be utf-8 encoded (unix style line ending).
• If a file has mismatched matching-pairs, the script will display the
file name, and the line number and column number of the first
instance where a mismatched bracket occures. (or, just the char number
instead (as in emacs's “point”))
• the matching pairs are all single unicode chars. They are these and
nothing else: () {} [] “” ‹› «» 【】 〈〉 《》 「」 『』
Note that ‘single curly quote’ is not consider matching pair here.
• You script must be standalone. Must not be using some parser tools.
But can call lib that's part of standard distribution in your lang.
Here's a example of mismatched bracket: ([)], (“[[”), ((, 】etc. (and
yes, the brackets may be nested. There are usually text between these
chars.)
I'll be writing a emacs lisp solution and post in 2 days. Ι welcome
other lang implementations. In particular, perl, python, php, ruby,
tcl, lua, Haskell, Ocaml. I'll also be able to eval common lisp
(clisp) and Scheme lisp (scsh), Java. Other lang such as Clojure,
Scala, C, C++, or any others, are all welcome, but i won't be able to
eval it. javascript implementation will be very interesting too, but
please indicate which and where to install the command line version.
I hope you'll find this a interesting “challenge”. This is a parsing
problem. I haven't studied parsers except some Wikipedia reading, so
my solution will probably be naive. I hope to see and learn from your
solution too.
i hope you'll participate. Just post solution here. Thanks.
Xah
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 02:32 AM, Ian Kelly wrote: Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. Setting an editor to read a tab as 8 spaces is just plain silly if your display is limited to 80 characters/line. Inserting 8 spaces as one indent is also a bit silly, but if you're going to do it, it's your responsibility to make sure the line is still less than 80 characters. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIpSlAAoJEPiOA0Bgp4/L7JwH/3zysmIUDPyy6f4X7oKAFye0 YcjgC5vM5gHQ4HGemGrIGBuurYffcC1XL3Cf7V5y4Rf6F+XwueLN1C4YEl8r1dtw r+E6pVsFM4e5keLoWb4s+IeBu0HV6GqHyXkEmj8kV8QG9dZJbWML42+AwGauXdO/ IUne0zp1ojHbAY5lDVJnRako3hMyXuxJjpERZXXh/Qe+z9GyaQ4/AHrVFsYyWS3A ZE9L7y/Yv/Bba9DjYLs1sgFDGVF996yQFAnhPw52cmlahh3/1vbpV+CPQhIeVVH8 PqObrFw9cdAMoo/kVoPRmcNBU+Xf9tlTDUS5w6bn7WjrYdnd28VesZ03uaapWx8= =tWjf -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sat, 16 Jul 2011 19:29:30 -0500) Of everything I've read on tabs vs. spaces, this is what makes the most sense to me: http://www.iovene.com/61/ Interesting one, especially the - from the coder's point of view - artificial distinction between indentation and alignment. What is the difference between indentation and alignment? Well, indentation works with tabs, alignment not. The author's conclusion simply just use what ever you want for indenting, but use spaces for aligning leaves only two choices for Python programmers: use spaces for indenting or don't align. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. I'm still looking for the perfect programming font. Suggestions welcomed. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 03:15 AM, Dotan Cohen wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I really would like to know why anyone would use a non-fixed-width font for programming. I'm still looking for the perfect programming font. Suggestions welcomed. I use Courier New. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIp7iAAoJEPiOA0Bgp4/LWzcH/0iHzlOF47JOnIJfPjbhhTu5 KbrkE3mkQEwDtdNT4FUQb/aklHqvlmd4DWgxg25eXZ8PWAfQBPjnfKWHDSvWz7+2 rt6MNXLfh/6wzAAAT2nJNl5QabeANYBEbSE3EvgnMe5LfVWR/vVl2upmTfxAaoWJ gH1Vp6TstAZluh8kcmii8dyrHXiubh9K84YS+FdRzLX3lz5mtGe+c20DWeeMiMxU NlIzfWQVzZa4avU+1GdWFXwgKJP5chf7lyrg1UKFmSeQUeR4MeOx1PP8spkQy51i fl4+VCCHOxL3Z5KVrM/aO0wTNwjYy+QddkGr+Hdk/QDNoqJwwYi8e2Nao/06HUY= =3pB7 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 02:56 AM, Thorsten Kampe wrote: What is the difference between indentation and alignment? Well, indentation works with tabs, alignment not. The use of spaces for indentation is as much of a hack as the use of tabs for alignment is. Not everyone agrees on how many spaces an indent should be (whether an indent is a tab or a space-tab), which is a good reason to use tabs. In fact, spaces have absolutely /no/ advantage over tabs when it comes to pure indentation. It may be possible to configure an editor to compensate using space-tabs (and perhaps even detect the length of indents, changing the number of spaces to conform to what the reader thinks is the right number of spaces per indent), but this is all to make a pretty delicate environment just to be even with tabs. On the flip side, tabs can't maintain alignment because again, not everyone agrees on how big a tab should be. This is a good reason to use spaces. Using tabs for indentation and spaces for alignment solves the problem. I really can't think of any problems this would cause that aren't superficial. The author's conclusion simply just use what ever you want for indenting, but use spaces for aligning leaves only two choices for Python programmers: use spaces for indenting or don't align. It's possible to indent with tabs and align with spaces in Python; see my earlier post. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIp8PAAoJEPiOA0Bgp4/LpjYIAIa+Qpw+1Uhsdv8R3NkH4yat h7axOgwpq2SqbU9KsJpmJbC737C2JWj3GrCzkSfExjlrG2Wv5qB7U5hgFbJVeTU/ 1paBZtXP0BZgXLEeZwlIKJDT3HF28sj7GCMFoP6KhX0v7oe7BsaRyriIBAQWX4Hh p8NrMfr16tkGQXFmTPyu5UHdiCX35/9ywR1hw96h4H1J6sht1Q6N47Xx4EI4DN/X eU5wY7qrJPjinYD7N3uQGpRhHKjTIAWRSPxFtN6voP9Y+6KGPH+e2eDFV06h8Hi1 /tPQtbfWROdN1c10TL57FDBqW+Q32gMB3z60/XMPWhB5Mz0a/dFLou5bdDhvtvc= =w8GN -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sun, 17 Jul 2011 03:36:31 -0500) Not everyone agrees on how many spaces an indent should be (whether an indent is a tab or a space-tab), which is a good reason to use tabs. Not everyone who doesn't agree on indent size actually cares enough about indent size - especially in someone else's code. I'd say it's probably rather the majority making this whole debate artificial. I like my indent four spaces. If you like eight, wonderful, I don't care, it's your code. If I want to use your code in my own, I completely have to reformat your code anyway. And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. This whole debate is artificial. Using tabs for indentation and spaces for alignment solves the problem. I really can't think of any problems this would cause that aren't superficial. Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: FULL TIME PYTHON DEVELOPER OPPORTUNITY IN CHICAGO, IL
On 07/07/2011 21:48, Aimee Gerzofsky wrote: Python Developer Major financial clients is seeking a PythonDeveloper for a *full time position in Chicago, IL*. It's better to post this kind of thing to the python job board: http://www.python.org/community/jobs/howto/ cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Jul 17, 12:47 am, Xah Lee xah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 04:33 AM, Thorsten Kampe wrote: Not everyone who doesn't agree on indent size actually cares enough about indent size - especially in someone else's code. I'd say it's probably rather the majority making this whole debate artificial. It's more of a debate on what's good practice when sharing with others (especially when many developers work together and there are no strict guidelines enforced, which is not uncommon with large open-source projects). Obviously, one can completely disregard all guidelines for writing readable and maintainable code, and no one will care if no one sees it. And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. How is indent size unimportant with regard to formatting? Or are you talking about design as part of formatting? This whole debate is artificial. Only if no one cares about your code. Sometimes that's more or less the case, and sometimes it isn't. It's also worth mentioning that some people have an almost religious fervor when it comes to spaces and tabs. That can make the issue much more relevant than other things that are more important. Many editors can work around either style (at least in some sense), so in many circumstances, it is indeed artificial, but there are other circumstances where it matters a lot (often more than it should). Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIrMtAAoJEPiOA0Bgp4/LlHIH/j42a2rms3GDPzAkl8iLZvCq okJULVeqxAeW4gKFDnPHaagyqqj+d+jbeuEArPU0i3PPEaajCFk/0h53D6tP3lpf Gt8Iyg5cPjmnUchIuwdI1evSISIJoKU44m2x6W3joDzy+fqHfy14K8wdVV69oTKk YzUb/5mU2/xyW0ULpOMCQwTSBsbE+bQxPEoULNPoUHR0bglPqgrDkHlFkD6iOVRt IpL4exPXM8OxKknir7omN7mHNXD2InJqV2QE6nHwirywMxVrWtuIpM4YQ2RhRdES zfjelskyvp2KOG+VwLxaYmHHbonzRyMJY51w4kw2C7y4nAYzjiN5z4rgLrPyo2w= =FKP/ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Code hosting services
Thomas Jollans t...@jollybox.de writes: Launchpad has a cross-project bug tracker. With which you can (so I'm told) interact with completely using email. Launchpad also uses the excruciatingly slow (but distributed, and written-in-python) bzr for version control. Citation needed. While Git is the fastest, Bazaar (so long as you're using a non-ancient version) is plenty fast enough for most needs. -- \ “The face of a child can say it all, especially the mouth part | `\of the face.” —Jack Handey | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Code hosting services
On 07/17/2011 12:08 PM, Ben Finney wrote: Thomas Jollans t...@jollybox.de writes: Launchpad has a cross-project bug tracker. With which you can (so I'm told) interact with completely using email. Launchpad also uses the excruciatingly slow (but distributed, and written-in-python) bzr for version control. Citation needed. While Git is the fastest, Bazaar (so long as you're using a non-ancient version) is plenty fast enough for most needs. You asked for it: I cite: http://whygitisbetterthanx.com/#git-is-fast Of course, I haven't used bzr in ages, and the data on that website is pretty old. You say bzr has improved, and I'll take your word for it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. How is indent size unimportant with regard to formatting? Take some code or yours and format it with three and with six spaces. Then you will see how unimportant it is: it looks virtually the same. Or as I've written in another posting: There is for instance maximum line length, the number of empty lines, the author's method of alignment, spaces between the equals sign and so on. These are all much more dominant in the source code and none of this is left for the reader's disposition. Compare for instance variable= 11 anothervariable = 22 def whatever (prettylong = 1, alsoprettylong = 22, anotherone = 33): pass to variable=11 anothervariable=22 def whatever (prettylong=1, alsoprettylong=22, anotherone=33): pass This whole debate is artificial. Only if no one cares about your code. Only if you don't care about indent length - which I again state, most people (probably) don't. It's also worth mentioning that some people have an almost religious fervor when it comes to spaces and tabs. I know. These are people like rantingrick who start artificial threads like this with artificial problems like tabs versus spaces to liberate the common coder. Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. Or your example: setup( name = 'Elucidation', version = '0.0.1-WIP', py_modules = ['elucidation'], author = 'Andrew Berg', author_email = 'baha...@digital-signal.net', url = '', platforms= 'Windows', description = 'Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools.' ) The keywords are aligned by indenting. In the left of an assignment case it makes a difference for the Python compiler, in the alignment case it doesn't. In both cases, it makes a difference to the human who indents/aligns to group similar things and blocks. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal to extend PEP 257 (New Documentation String Spec)
On 07/16/2011 10:10 PM, Steven D'Aprano wrote: But I've never come across an email client that messes with attachments. Just send your code as an attached .py file and it's all good. However I'm on a couple mailing lists (e.g. lurking on OpenBSD) that strip all attachments... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 11:35, Andrew Berg bahamutzero8...@gmail.com wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I don't find that fixed-width fonts are ugly, but variable-width fonts sure are more of a pleasure. And with code-colouring in any good IDE, there is no real need to have the dot or other tiny characters jump out and announce their presence. So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? I really would like to know why anyone would use a non-fixed-width font for programming. Aesthetics. I'm still looking for the perfect programming font. Suggestions welcomed. I use Courier New. Have you looked at the Droid fixed-width fonts? Very nice, and easy to distinguish 0 from o or O. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 4:11 pm, Dotan Cohen dotanco...@gmail.com wrote: On Sun, Jul 17, 2011 at 11:35, Andrew Berg bahamutzero8...@gmail.com wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I don't find that fixed-width fonts are ugly, but variable-width fonts sure are more of a pleasure. And with code-colouring in any good IDE, there is no real need to have the dot or other tiny characters jump out and announce their presence. So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? I really would like to know why anyone would use a non-fixed-width font for programming. Aesthetics. Its more (or less depending...) than just aesthetics. Its about optimization. On a fixed width font an 'i' is as wide as an 'm' as a '.' This means that a fwf is either a unreasonably small or the lines are too long. [Note: I use only fwf because all the tools I know/use/tried are broken for vwf] -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee xah...@gmail.com wrote: the problem is to write a script that can check a dir of text files (and all subdirs) and reports if a file has any mismatched matching brackets. I wonder will it be possible to code the whole thing as a single regular expression... I'm pretty sure it could be done as a sed or awk script, but I'm insufficiently expert in either to do the job. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Jul 17, 4:34 pm, Chris Angelico ros...@gmail.com wrote: On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee xah...@gmail.com wrote: the problem is to write a script that can check a dir of text files (and all subdirs) and reports if a file has any mismatched matching brackets. I wonder will it be possible to code the whole thing as a single regular expression... I'm pretty sure it could be done as a sed or awk script, but I'm insufficiently expert in either to do the job. ChrisA No possible: See http://en.wikipedia.org/wiki/Pumping_lemma_for_regular_languages#Use_of_lemma Informally stated as regexes cant count. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: I can't fathom why 8 position tabs were *ever* the default, let alone why they are still the default. That's because they were not invented as a means for programmers to vary indentation. Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. The notion that whitespace characters are inserted into the text would have been very alien to someone using text processing software anno 1970. Same thing with space and enter; on typewriters the space bar doesn't type anything onto the paper, it moves to the next column, and that thinking carried over to computers. The reason the tab stop is a full 8 positions: for faster navigation. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Skip a column or two too far? Adjust by backspacing (another navigation key). As for why 8 is still the default - well, what else should it be? 2, 3, 4, 5? I for one am thankful that we have so far been spared the flamewar armegeddon of all the world's programmers trying to agree on that. Cameron Simpson wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. Just like in the old days:) regards, Anders -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ HTH ___ ¹ http://en.wiktionary.org/wiki/indenting ² http://en.wikipedia.org/wiki/Indent_style ³ http://en.wiktionary.org/wiki/aligning -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Dotan Cohen wrote: On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. Not using a fixed-width font avoids this problem and others in the first place. I'm still looking for the perfect programming font. Suggestions welcomed. I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are designed for programming and are near perfect in that regard. However, I have decided for Deja Vu Sans Mono for reading and writing Usenet articles because it supports more Unicode characters and can be sized appropriately for running text. But, all of them are fixed-width fonts. I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Ian Kelly wrote: but if somebody later tries to edit the file using 8-space tabs I came across this and I like to put a note on top of the script to remember to modify it accordingly. -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On 07/17/2011 11:48 AM, Raymond Hettinger wrote: On Jul 17, 12:47 am, Xah Leexah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL Ruby solution: https://gist.github.com/1087583 Kind regards robert -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
Am 17.07.2011 15:20, schrieb Robert Klemme: On 07/17/2011 11:48 AM, Raymond Hettinger wrote: On Jul 17, 12:47 am, Xah Leexah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL Ruby solution: https://gist.github.com/1087583 I acutally don't know Ruby that well, but it looks like your program recognizes [(]) as correct although it is not, because you translate [(]) to (()) (which is indeed correct, but does not resemble the input correctly anymore). Kind regards robert -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
Chris Angelico wrote:
On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee xah...@gmail.com wrote:
the problem is to write a script that can check a dir of text files
(and all subdirs) and reports if a file has any mismatched matching
brackets.
I wonder will it be possible to code the whole thing as a single
regular expression... I'm pretty sure it could be done as a sed or awk
script, but I'm insufficiently expert in either to do the job.
Did you notice the excessive crosspost? Please do not feed the troll.
In the classical sense is not possible, as classical regular expressions
have no concept of recursion. Indeed, matching brackets are a textbook
example for a non-regular¹ context-free language L = {a^n b^n; n 0} that
can only be recognized by a pushdown automaton (PDA). (Finite automata
cannot count.)
However, it is possible (and done) to use classical regular expressions or
non-recursive Regular Expressions (note the different character case) to
match tokens more efficiently with a PDA implementation. This is commonly
called a parser. (Programming languages tend to be specified in terms of a
context-free grammar – they tend to be context-free languages –, which is
why a parser is a part of a compiler or interpreter. See for example
Python.²)
It is possible, with Perl-compatible Regular Expressions (PCRE), provided
that you have enough memory, to use such an extended Regular Expression (not
to be confused with EREs³)⁴:
\((([^()]*|(?R))*)\)
However, even Python 3.2 does not support those expressions (although it
supports some other PCRE patterns, like named subexpressions)⁵, neither do
standard and forked versions of sed(1) (BREs, EREs, using an NFA) nor awk
(EREs, using a DFA or NFA). [That is not to say it would not be possible
with Python, or sed or awk (both of which are off-topic here), but that more
than a Regular Expression would be required.]
On this subject, I recommend reading the preview chapters of the second and
third editions, respectively, of Jeffrey E. F. Friedl's Mastering Regular
Expressions, which are available online for free at O'Reilly.com⁶.
HTH.
__
¹ because it can be proved that the pumping lemma for regular languages
does not apply to it; see also
http://en.wikipedia.org/wiki/Chomsky_hierarchy pp.
² http://docs.python.org/reference/
³ http://en.wikipedia.org/wiki/Regular_expression
⁴ Cf. http://php.net/manual/en/regexp.reference.recursive.php
⁵ http://docs.python.org/library/re.html
⁶ http://oreilly.com/catalog/regex/chapter/ch04.html,
http://oreilly.com/catalog/9780596528126/preview#preview
--
PointedEars
Bitte keine Kopien per E-Mail. / Please do not Cc: me.
--
http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Sunday, July 17, 2011 10:12:27 AM Xah Lee did opine:
2011-07-16
folks, this one will be interesting one.
the problem is to write a script that can check a dir of text files
(and all subdirs) and reports if a file has any mismatched matching
brackets.
• The files will be utf-8 encoded (unix style line ending).
• If a file has mismatched matching-pairs, the script will display the
file name, and the line number and column number of the first
instance where a mismatched bracket occures. (or, just the char number
instead (as in emacs's “point”))
• the matching pairs are all single unicode chars. They are these and
nothing else: () {} [] “” ‹› «» 【】 〈〉 《》 「」 『』
Note that ‘single curly quote’ is not consider matching pair here.
• You script must be standalone. Must not be using some parser tools.
But can call lib that's part of standard distribution in your lang.
Here's a example of mismatched bracket: ([)], (“[[”), ((, 】etc. (and
yes, the brackets may be nested. There are usually text between these
chars.)
I'll be writing a emacs lisp solution and post in 2 days. Ι welcome
other lang implementations. In particular, perl, python, php, ruby,
tcl, lua, Haskell, Ocaml. I'll also be able to eval common lisp
(clisp) and Scheme lisp (scsh), Java. Other lang such as Clojure,
Scala, C, C++, or any others, are all welcome, but i won't be able to
eval it. javascript implementation will be very interesting too, but
please indicate which and where to install the command line version.
I hope you'll find this a interesting “challenge”. This is a parsing
problem. I haven't studied parsers except some Wikipedia reading, so
my solution will probably be naive. I hope to see and learn from your
solution too.
i hope you'll participate. Just post solution here. Thanks.
Xah
This is a very old solution, some of it nearly 30 years old.
Written in C, the trick is in doing it in python I guess.
==begin cntx.c===
/*^k^s
.ds2
.hb
.fb^k^s^b Cntx.c, page #^k^s^b
*
* *
* CC (C Checker) *
* *
* C Source Brackets, Parenthesis, brace,*
*quote and comment Checker *
* *
*T. Jennings -- Sometime in 1983 *
*Slightly tweaked and renamed MINILINT *
* KAB Aug 84 *
*Ported to OS9 and further tweaked *
* Brian Paquette March 91 *
* Brackets, single, double quote counters added*
*renamed Cntx 04/09/91*
* by Gene Heskett *
* *
* some additional code for ignoring syntax chars inside of *
* double quoted strings added 3/21/93 by Gene Heskett *
* same for single quoted stuffs 7/10/93 by Gene Heskett*
* And long lines handling ability added too.*
* Adding tab ignorers and a counter to tally how many 11/21/93 *
/
#define OS9 /* used for nested comment handling*/
/* comment out for non OS9/6809*/
#include stdio.h
#include ctype.h
#include string.h
#define FALSE 0
#define TRUE 1
#ifdef OS9
#define NO No
#define YES Yes
char *cmnt;
#endif
/* Very crude but very effective C source debugger. Counts the numbers of
matching braces, parentheses and comments, and displays them at the left
edge of the screen. The best way to see what it does is to do it; try
cntx -v cntx.c
Properly handles parens and braces inside comments; they are ignored.
Also ignores single quotes if doubles are odd number, so singles
can be used in a printf string for punctuation. IF you see the doubles
are odd at line end (the printout tally), all bets are OFF!
Enter cntx on the command line by itself for a usage note.
*/
main(argc,argv)
int argc;
char *argv[];
{
FILE *f;
char c,secnd_c,lastc;
int bracket,parens,braces,squote,dquote,comments;
int perr,bkerr,brerr,sqerr,dqerr;
int verbose,okay;
int filearg = 0;
int line, col, tabc;
if ((argc 2)||(argc 3)) getout(0);
if (argc == 3)
{
verbose = TRUE; /* already tested for -v switch */
if((argv[1][0] == '-') (toupper(argv[1][1]) == 'V'))
filearg = 2; /*file name pointed to by argv[2] */
if((argv[2][0] == '-') (toupper(argv[2][1]) == 'V'))
filearg = 1;
if(!filearg)
Re: Tabs -vs- Spaces: Tabs should have won.
On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine: On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200) Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ *doublesigh* that is actually the point I was trying to make. From a programmer's point of view the distinction is artificial because he does essentially the same: press the tab key or the indent button to move the stuff right from the cursor to the right so it gets aligned with the stuff above. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* gene heskett (Sun, 17 Jul 2011 10:29:03 -0400) On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine: I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:32 am, Ian Kelly ian.g.ke...@gmail.com wrote: This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Solution: STOP USING BROKEN TOOLS!!! Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. Of course it is. The litmus test will be four-space-tab-view. If the code overflows in this view type then the code will fail the 80 char maximum limit. This argument is ridiculous anyhow. It is up to you how to view the source. If you view it in 80 width tabs don't start complaining later when one indention goes off the page. Would you view the source with 50 point font? Jeez. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. THEIR LINES is the key words. A tab control is a tab control is a (you guessed it!) a tab control. No matter how small or large your tab settings are the source only reflects one tab control char per press of the tab key. Heck, people are already (unwisely) using 8-space- spaces and i don't hear you making the same argument. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. We already mandate four space spaces so what is the difference? I'll tell you, the difference is Freedom and Unity living in perfect harmony. Yes, we mandate that all code must meet the 80 line limit in four- space-tab-view, and if it doesn't, it's not allowed in the stdlib. Plain and simple. -- http://mail.python.org/mailman/listinfo/python-list
HOT HOT HOT
FOR GOOD JOBS SITES TO YOU http://goodjobssites.blogspot.com/ FOR HOT PHOTOVIDEOS KATRINA KAIF RARE PHOTOS http://southactresstou.blogspot.com/2011/07/katrina-kaif-wallpapers.html TAMANNA HOT SEXY PHOTOS VIDEOS http://southactresstou.blogspot.com/2011/07/tamanna-wallpapers.html PRANITHA LATEST BEAUTIFUL PHOTOS http://southactresstou.blogspot.com/2011/06/about-pranitha-praneetha-is-beautiful.html KAJAL AGARWAL HOT SEXY PHOTOS http://southactresstou.blogspot.com/2011/05/kajal-agarwal.html KATRINA KAIF IN BEAUTIFUL RED DRESS http://southactresstou.blogspot.com/2011/05/katrina-kaif_22.html GOOD LOOKING DEEPIKA PADUKONE http://southactresstou.blogspot.com/2011/05/deepika-padukone_22.html AISHWARYA RAI UNBELIVABLE PHOTO http://southactresstou.blogspot.com/2011/05/aishwarya-rai.html FOR FAST UPDATES IN TELUGU FILM INDUSTRY http://allyouwants.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Jul 17, 9:47 am, Xah Lee xah...@gmail.com wrote:
2011-07-16
folks, this one will be interesting one.
the problem is to write a script that can check a dir of text files
(and all subdirs) and reports if a file has any mismatched matching
brackets.
• The files will be utf-8 encoded (unix style line ending).
• If a file has mismatched matching-pairs, the script will display the
file name, and the line number and column number of the first
instance where a mismatched bracket occures. (or, just the char number
instead (as in emacs's “point”))
• the matching pairs are all single unicode chars. They are these and
nothing else: () {} [] “” ‹› «» 【】 〈〉 《》 「」 『』
Note that ‘single curly quote’ is not consider matching pair here.
• You script must be standalone. Must not be using some parser tools.
But can call lib that's part of standard distribution in your lang.
Here's a example of mismatched bracket: ([)], (“[[”), ((, 】etc. (and
yes, the brackets may be nested. There are usually text between these
chars.)
I'll be writing a emacs lisp solution and post in 2 days. Ι welcome
other lang implementations. In particular, perl, python, php, ruby,
tcl, lua, Haskell, Ocaml. I'll also be able to eval common lisp
(clisp) and Scheme lisp (scsh), Java. Other lang such as Clojure,
Scala, C, C++, or any others, are all welcome, but i won't be able to
eval it. javascript implementation will be very interesting too, but
please indicate which and where to install the command line version.
I hope you'll find this a interesting “challenge”. This is a parsing
problem. I haven't studied parsers except some Wikipedia reading, so
my solution will probably be naive. I hope to see and learn from your
solution too.
i hope you'll participate. Just post solution here. Thanks.
I thought I'd have some fun with multi-processing:
https://gist.github.com/1087682
--
http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Sun, 17 Jul 2011 02:48:42 -0700 (PDT) Raymond Hettinger pyt...@rcn.com wrote: On Jul 17, 12:47 am, Xah Lee xah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL I'm new to Python. I think I'd have done it in a similar way (in any language). Your use of openers/closers looks nice though. In the initialization of openers, I guess you implicitly create a kind of hash, right? Then the 'in' operator checks for the keys. That is elegant because you have the openers and closers right next to each other, not in separate lists. But why do you enumerate with start=1? Shouldn't you start with index 0? -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On 07/17/2011 03:55 PM, mhenn wrote: Am 17.07.2011 15:20, schrieb Robert Klemme: On 07/17/2011 11:48 AM, Raymond Hettinger wrote: On Jul 17, 12:47 am, Xah Leexah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL Ruby solution: https://gist.github.com/1087583 I acutally don't know Ruby that well, but it looks like your program recognizes [(]) as correct although it is not, because you translate [(]) to (()) (which is indeed correct, but does not resemble the input correctly anymore). Right you are. The optimization breaks the logic. Good catch! Kind regards robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Excerpts from Thorsten Kampe's message of Sun Jul 17 11:10:57 -0400 2011: The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. I use inconsolata, but I hate the look of it un-bold at small sizes, so I keep it bold all the time. I've started using DejaVu very recently because of that, it looks better on screen at small sizes (pixelsize=9 in my ~/.Xdefaults, as opposed to the 12 and bold with inconsolata). Inconsolata looks great on paper, though. DejaVu Sans Mono isn't the prettiest thing but it certainly gets the job done. -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Ordered list question
I'm currently working on a project where I'm looping through xml elements,
pulling the 'id' attribute (which will be coerced to a number) as well as the
element tag. I'm needing these elements in numerical order (from the id).
Example xml might look like:
price id=5
copyright id=1
address id=3
There will be cases where elements might be excluded, but I'd still need to
put what I find in id numerical order. In the above example I would need
the order of 1, 3, 5 (or copyright, address, price). In javascript I can
easily
index an array, and any preceding elements that don't exist will be set to
'undefined':
-
var a = [];
a[parseInt('5')] = 'price';
a[parseInt('1')] = 'copyright';
a[parseInt('3')] = 'address';
// a is now [undefined, copyright, undefined, address, undefined, price]
-
Next, I can loop through the array and remove every 'undefined' in order to
get the ordered array I need:
-
var newA = [];
for (var x = 0; x a.length; x++) {
if (a[x] != undefined) {
newA.push(a[x]);
}
}
// newA is now [copyright, address, price]
-
My question is, does python have a similar way to do something like this?
I'm assuming the best way is to create a dictionary and then sort it by
the keys?
Thanks.
Jay
--
http://mail.python.org/mailman/listinfo/python-list
Re: Ordered list question
On Mon, Jul 18, 2011 at 2:28 AM, jyoun...@kc.rr.com wrote: My question is, does python have a similar way to do something like this? I'm assuming the best way is to create a dictionary and then sort it by the keys? That would be one way to do it. If you know beforehand what the highest ID is, you could create a list and treat it exactly the way you're treating the Javascript array, but I think the dictionary is probably a better option. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:35 am, Thorsten Kampe thors...@thorstenkampe.de wrote:
* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
3) Tabs create freedom in the form of user controlled indention.
Indention width should be a choice of the reader NOT the author. We
should never code in indention width; but that is EXACTLY what we
are doing with spaces! No, the reader should be able to choose the
indention width without ANY formatting required or without any
collateral damage to the source code. Tabs offer freedom, spaces offer
oppression.
Why are you so obsessed with indentation length? Indentation length is
just /one/ of the formatting choices that the author makes for the
reader - and probably the /least/ significant one.
I am not OBSESSED with it, i am just PERTURBED that we are not using
tabs; since tabs offer freedom to view the source at ANY indentation
level you choose REGARDLESS of what the author thought was
appropriate. It is a wise choice to only allow tabs in a language that
has FORCED indention. This is one way we can actually promote freedom
whist maintaining unity.
There is for instance maximum line length,
I like to keep lines at 80. Sometimes i go over if the code is not
something you would need to read often. If the code was to go into the
stdlib i would make sure it was 110% style guide compliant.
the number of empty lines,
I hate vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.
the author's method of alignment, spaces between the equals sign and so
on.
I believe non-compliant spacing in args should throw an syntax error.
I hate this:
func( arg1 = 1, arg2 = 3 )
It should be...
func(arg1=1, arg2=3)
Much easier to read when formatted into logical groups.
These are all much more dominant in the source code and none of
this is left for the reader's disposition.
It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.
Compare for instance
variable = 11
anothervariable = 22
def whatever (prettylong = 1,
alsoprettylong = 22,
anotherone = 33):
pass
to
variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
pass
Both examples show non-compliance to the Python style guide.Except for
this...
--
FUNCTIONS/METHODS
--
def whatever(
prettylong=1,
alsoprettylong=22,
anotherone=33):
OR
def whatever(prettylong=1, alsoprettylong=22,
anotherone=33):
I think the second is more readable for block openers. Note the
closing bracket and colon on last line!
--
CONTAINER TYPES
--
d = {
1:1,
2:2,
3:3,
4:4,
}
Note closing bracket on newline; and all alone! For hand stitching
containers you should put the closer on a newline that matches the
opener's indention level.
--
VARIABLES
--
variable = 11
anothervariable = 22
Stop trying to be an individual in a community. When you write code
for just you then write it any way you like. Go ahead and use that
Joker font and 10 space indention. Go ahead an use foolish spacing and
whatever. However when you are writing code in public or for the
stdlib you should always be Style Guide compliant.
You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 5:42 am, Thorsten Kampe thors...@thorstenkampe.de wrote: When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. Or your example: setup( name = 'Elucidation', version = '0.0.1-WIP', py_modules = ['elucidation'], author = 'Andrew Berg', author_email = 'baha...@digital-signal.net', url = '', platforms = 'Windows', description = 'Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools.' Why do you feel the need to layout your code in a GUI-listview manner. Next you'll want column titles and column sorting... Jeez! This is what you should have done... DESC = Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools. setup( name='Elucidation', version='0.0.1-WIP', py_modules=['elucidation'], author='Andrew Berg', author_email='baha...@digital-signal.net', url='', platforms='Windows', description=DESC, ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 2:29 AM, rantingrick rantingr...@gmail.com wrote: You guys should feel lucky i am not the BDFL, because i would cast plagues of exceptions on your lazy butts! BDFL = Benevolent Dictator For Life. Note that first word. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On 07/17/2011 06:01 PM, Robert Klemme wrote: On 07/17/2011 03:55 PM, mhenn wrote: Am 17.07.2011 15:20, schrieb Robert Klemme: On 07/17/2011 11:48 AM, Raymond Hettinger wrote: On Jul 17, 12:47 am, Xah Leexah...@gmail.com wrote: i hope you'll participate. Just post solution here. Thanks. http://pastebin.com/7hU20NNL Ruby solution: https://gist.github.com/1087583 I acutally don't know Ruby that well, but it looks like your program recognizes [(]) as correct although it is not, because you translate [(]) to (()) (which is indeed correct, but does not resemble the input correctly anymore). Right you are. The optimization breaks the logic. Good catch! Turns out with a little possessiveness I can fix my original approach which has the added benefit of not needing three passes through the file (the two #tr's are obsolete now). https://gist.github.com/1087583 Cheers robert -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 4:49 am, Anders J. Munch 2...@jmunch.dk wrote: Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. The notion that whitespace characters are inserted into the text would have been very alien to someone using text processing software anno 1970. Same thing with space and enter; on typewriters the space bar doesn't type anything onto the paper, it moves to the next column, and that thinking carried over to computers. And how much longer are we going to live in the past? Who cares about backward compatible tabs. Mandate the four space tab now! Mandate that Python takes four space and four space only! We shall lead the charge for universal tab unity in all programming languages. How long are you going to accept this multiplicity? It's ridiculous. The reason the tab stop is a full 8 positions: for faster navigation. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Just in case you were not aware this the year 2011. Spreadsheets have been around for a LONG time. Stop living the past. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. Put your money - or, in this case, development time - where your big ranting mouth is. Prove that your ideas are worth something by acting on them. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal to extend PEP 257 (New Documentation String Spec)
On Jul 17, 6:11 am, Tim Chase python.l...@tim.thechases.com wrote: On 07/16/2011 10:10 PM, Steven D'Aprano wrote: But I've never come across an email client that messes with attachments. Just send your code as an attached .py file and it's all good. However I'm on a couple mailing lists (e.g. lurking on OpenBSD) that strip all attachments... If this IS true then format your source with indentation- markers (---) and tell the receiver to run str.replace() on the source. Also you should send a rant to the list owner concerning this atrocious striping behavior. But then again, you could just post it to a paste bin or email it to group members directly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 12:11 pm, Chris Angelico ros...@gmail.com wrote: On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. It's funny you mention this because i am creating a specification for a Python 4000 fork that removes all ambiguities and multiplicity from the language. Very soon i will be posting the spec for review within this group. Maybe some of you will come to your senses and start implementing these important features in CPython. If not, i am not going to waste my time forever trying to convince idiots that the world is in fact round. Python as it stands now will be defunct unless we make some serious changes starting with formatting. We cannot continue to create code bases that are so haphazardly written just for the sake of personal freedom. Since people will not self-police we must create a mandate that forces compliance to a style guide. Years have passed since the first program was written. It is high time to set the standards for formatting. Such a system of rigorous formatting rules requires much less interpreter logic. Python will be leaner and meaner. There won't be any more arguing about how to format code. There will only be one way; the correct way! Choose to follow it or die of exceptions; your choice. I am looking to the future and leaving the past where it belongs. After i get a format style nailed down i will start culling the other language specific multiplicities. Then it will be time to look outside of Python and see what is the future of high level programming languages. You can choose to join me or choose to rot of old age in the self- induced hell of antiquity. The past is bickering over selfish personal freedoms, the future of is unity. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 3:57 AM, rantingrick rantingr...@gmail.com wrote: It's funny you mention this because i am creating a specification for a Python 4000 fork that removes all ambiguities and multiplicity from the language. Very soon i will be posting the spec for review within this group. Maybe some of you will come to your senses and start implementing these important features in CPython. If not, i am not going to waste my time forever trying to convince idiots that the world is in fact round. Oh, I totally agree. And mailman is open source software so you can even host the new Python-4000 mailing list yourself! Gather unto thyself thy followers, and begin anew the creation of the world. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
4) Tabs remove the need for complicated indention/detention tools. On 07/17/2011 10:15 AM, rantingrick wrote: On Jul 17, 2:32 am, Ian Kellyian.g.ke...@gmail.com wrote: This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Solution: STOP USING BROKEN TOOLS!!! Unbroken tools that do anything worthwhile are usually complicated tools. Just pointing that out in case you missed the irony... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* rantingrick (Sun, 17 Jul 2011 10:57:10 -0700 (PDT)) Choose to follow it or die of exceptions; your choice. One of the best things I've read for a long time :-). The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 9:15 AM, rantingrick rantingr...@gmail.com wrote: I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. THEIR LINES is the key words. A tab control is a tab control is a (you guessed it!) a tab control. No matter how small or large your tab settings are the source only reflects one tab control char per press of the tab key. Heck, people are already (unwisely) using 8-space- spaces and i don't hear you making the same argument. Because the problem does not apply. If I use 4 spaces, and somebody else opens my file who uses 8, the code will still be limited to 80 columns. They will just have to see my ugly 4-space indentation instead of their preferred 8-space indentation. You know what? They can cope. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. We already mandate four space spaces so what is the difference? I'll tell you, the difference is Freedom and Unity living in perfect harmony. Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 10:29 AM, rantingrick rantingr...@gmail.com wrote: I hate vertical white-space. I follow Python style guide suggestions, and then some! I hate when people insert spaces into code blocks and function/method bodies. If you feel a space must be inserted then that is a good clue you should be using a comment there instead. Vertical breaks should only happen before and after classes, methods, functions, groups of GLOBALS, groups of import statements. Think of func/method bodies as paragraphs and classes as sections of a book. Two vertical spaces between classes and one vertical space between func/methods. You know, there is such a thing as a vertical tab. If we're going to take your suggestion of mandating tabs (for greater freedom!), should we not follow it to its logical conclusion and mandate the usage of vertical tabs instead of multiple newlines? Then everybody could choose for themselves how many lines they want a vertical tab to represent It should be MANDATED. And these @holes who refuse to format their code in a community standard will suffer the plague of syntax errors. Who do these people think they are? Do they believe the rules do not apply to them? I'll tell you who they are, they are F'ING format criminals. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordered list question
jyoun...@kc.rr.com wrote:
^^
Something is missing there.
I'm currently working on a project where I'm looping through xml elements,
pulling the 'id' attribute (which will be coerced to a number)
No, usually it won't.
as well as the element tag.
That's element _type name_.
I'm needing these elements in numerical order (from the id).
Attribute values of type ID MUST NOT start with a decimal digit in XML [1].
Example xml might look like:
price id=5
copyright id=1
address id=3
That is not even well-formed, as the end tags of the `address', `copyright',
and `price' elements (in that order) are missing. Well-formed XML would be
either
foo
price id=5/
copyright id=1/
address id=3/
/foo
or
foo
price id=5
copyright id=1/
/price
address id=3/
/foo
or
foo
price id=5/
copyright id=1
address id=3/
/copyright
/foo
or
price id=5
copyright id=1/
address id=3/
/price
or
price id=5
copyright id=1
address id=3/
/copyright
/price
but neither might be Valid (or make sense). Check your DTD or XML Schema.
There will be cases where elements might be excluded, but I'd still need
to put what I find in id numerical order. In the above example I would
need the order of 1, 3, 5 (or copyright, address, price). In javascript I
can easily index an array, and any preceding elements that don't exist
will be set to 'undefined':
-
var a = [];
a[parseInt('5')] = 'price';
a[parseInt('1')] = 'copyright';
a[parseInt('3')] = 'address';
// a is now [undefined, copyright, undefined, address, undefined,
price] -
This is nonsense even in javascript (there really is no such language
[1]). In ECMAScript implementations like JavaScript you would write
var a = [];
a[5] = price;
a[1] = copyright;
a[3] = address;
as array indexes are only special object properties, and properties are
stored as strings anyway. However, the highest index you can store this
way, in the sense that it increases the `length' of the array, would be
2³²−2 (as the value of the `length' property ranges from 0 to 2³²–1).
Python's `list' type is roughly equivalent to ECMAScript's `Array' type.
Important differences include that apparently you cannot store as much items
in a Python list as in an ECMAScript Array –
for p in range(0, pow(2, 31)-1): a.append(p)
...
Traceback (most recent call last):
File stdin, line 1, in module
MemoryError
[Kids, don't try this at home!]
for p in range(0, pow(2, 31)): a.append(p)
...
Traceback (most recent call last):
File stdin, line 1, in module
OverflowError: range() result has too many items
–, and that you need to add enough items in order to access one (so there
are no sparse lists):
a[23] = 42
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: list assignment index out of range
(I was not aware of that.) Also, the access parameter must be integer:
a[23] = 42
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: list indices must be integers, not str
a[foo] = bar
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: list indices must be integers, not str
[Using a non-numeric or out-of-range parameter (see above) for bracket
property access on an ECMAScript Array means that the number of elements in
the array does not increase, but that the Array instance is augmented with a
non-element property, or an existing non-element property is overwritten;
this cannot happen with Python lists.]
Next, I can loop through the array and remove every 'undefined' in order
to get the ordered array I need:
Or you could be using an ECMAScript Object instance in the first place, and
iterate over its enumerable properties. This would even work with proper
IDs, but if you are not careful – chances of which your statements about the
language indicate – you might need further precautions to prevent showing up
of user-defined enumerable properties inherited from Object.prototype:
var o = {
5: price,
1: copyright,
3: address
};
or programmatically:
var o = {};
o[5] = price;
o[1] = copyright;
o[3] = address;
Then:
for (var prop in o)
{
/* get prop or o[prop] */
}
-
var newA = [];
for (var x = 0; x a.length; x++) {
Unless a.length changes:
for (var x = 0, len = a.length; x len; ++x) {
The variable name `x' should also be reserved for non-counters, e. g. object
references. Use i, j, k, and so forth in good programming tradition here
instead.
if (a[x] != undefined) {
if (typeof a[x] != undefined) {
as your variant would also evaluate to `false' if a[x] was `null', and would
throw an exception in older implementations at no advantage (however, you
might want to consider using `a[x] !== undefined' for recent implementations
only).
newA.push(a[x]);
}
}
// newA is now [copyright,
Re: Tabs -vs- Spaces: Tabs should have won.
Thorsten Kampe wrote: * Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200) Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ *doublesigh* that is actually the point I was trying to make. Well, you said you would align code *by indenting*, which is either nonsense following the not-so-uncommon definition of indenting that I presented, or you chose a particularly bad example to make your point (as it does not feature indentation at all). From a programmer's point of view the distinction is artificial because he does essentially the same: press the tab key But he should not, unless he uses the Tab key to insert spaces, because the *display width* of the Tab *character* is variable. *That* is the point! or the indent button to move the stuff right from the cursor to the right so it gets aligned with the stuff above. Indent button? -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe thors...@thorstenkampe.de wrote: * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. They do with tabs. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:20 pm, Thorsten Kampe thors...@thorstenkampe.de wrote: The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Not *exactly*. A tab is just a control char in a string that meant to convey a user defined space. When a text editor see's a tab in a string it uses the current user defined tab width and creates the proper space (or moves the proper distance) in the display. The tab control char carries no information as to how WIDE a tab must be, no, the editor makes that choice (based on user input or default). However a tab can be EQUAL to four spaces, or eight spaces , or even eight-eight spaces if the user wants it to. The same is true for font. A string contains chars and the display font is a decision for the editor to make (based on user input or default). We cannot always offer unity and freedom in a programming language. But there are some exceptions; one of which being tabs. -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Jul 17, 7:15 am, Thomas 'PointedEars' Lahn pointede...@web.de wrote: Did you notice the excessive crosspost? Please do not feed the troll. IMO, this was a legitimate cross post since it is for a multi-language programming challenge and everyone can learn from comparing the results. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn pointede...@web.de wrote: I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. Not using a fixed-width font avoids this problem and others in the first place. I'm still looking for the perfect programming font. Suggestions welcomed. I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are designed for programming and are near perfect in that regard. However, I have decided for Deja Vu Sans Mono for reading and writing Usenet articles because it supports more Unicode characters and can be sized appropriately for running text. I have used those three in the past. Terrific fonts each of them, especially Inconsolata if I remember correctly. But, all of them are fixed-width fonts. I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. The ambiguity has never been an issue for me. In the unlikely event that an l (el) is in the place of a pipe, the code won't compile and I'll get an error on the line in question. Though that has never actually happened: the IDE is double-checking way before the code gets to the compiler. Zero vs. O (oh), I've never had this issue either and even if one key was hit in place of the other (they are close by) then either the IDE or compiler would catch it, or it would result in a minor bug in a text string. It simply isn't an issue. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 17:29, gene heskett ghesk...@wdtv.com wrote: I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. Hey there Gene! Are you not on every mailing list on the internet old man?!? I have also come to the conclusion that the perfect woman, the perfect physics theory, and the perfect programming font are all illusions that men will stride their entire lives in search for but will never find. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Dotan Cohen (Sun, 17 Jul 2011 22:20:15 +0300) On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe thors...@thorstenkampe.de wrote: * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. They do with tabs. Indentation alignment will (because you're using only spaces). Otherwise it doesn't align (it can't), simply because of the variable-width. For instance (in a variable-width font): if a == b: var123= 22 varxyz456 = 333 ^ aligned not aligned Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 20:57, rantingrick rantingr...@gmail.com wrote: Such a system of rigorous formatting rules requires much less interpreter logic. Python will be leaner and meaner. There won't be any more arguing about how to format code. There will only be one way; the correct way! Choose to follow it or die of exceptions; your choice. Do you know that Python 4000 is the only language in the world whose vocabulary gets smaller every year?' -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Ordered list question
If you need read everything, then sort once, then a dictionary (or collections.defaultdict if you require undefined's) and a single sort at the end is probably the way to go. If you truly need an ordered datastructure (because you're reading one element, using things sorted, reading another element, using things sorted), then you're better off with a treap (good average case time) or red-black tree (decent average case time, but without as much fluctuation). On Sun, Jul 17, 2011 at 9:28 AM, jyoun...@kc.rr.com wrote: I'm currently working on a project where I'm looping through xml elements, pulling the 'id' attribute (which will be coerced to a number) as well as the element tag. I'm needing these elements in numerical order (from the id). -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 21:20, Thorsten Kampe thors...@thorstenkampe.de wrote: The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Four is the number thou shalt indent, and the number of the indenting shall be four. Six thou shalt not indent, neither indent thou two, excepting that thou then proceed to four. Eight is right out. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. For me, it's Terminus* (from sourceforge). Br. Waldek [*] As long as you don't need anything but iso8859-1. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anders J. Munch wrote: Steven D'Aprano wrote: I can't fathom why 8 position tabs were *ever* the default, let alone why they are still the default. That's because they were not invented as a means for programmers to vary indentation. Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. No, when you pressed the Tab key on a typewriter (BTDT), you advanced to the next tab _stop_. This made it easier to write tables (tab from tabulate) on a typewriter (the alternative was time-consuming and error- prone use of the space and backspace keys). With the evolution of the (personal) computer, its use in offices and at home, and peripheral devices like the dot matrix printer, typewriters fell out of common use, but the terms associated with them were incorporated into information technology language (cf. TTY, originally teletypewriter, e. g.). The reason the tab stop is a full 8 positions: for faster navigation. No, the reason is that table columns should be as far enough away from each other to be distinguishable. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Skip a column or two too far? I am getting the idea here that you mean the right thing, but that you explain it wrong. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:22 pm, Tim Chase python.l...@tim.thechases.com wrote: Solution: STOP USING BROKEN TOOLS!!! Unbroken tools that do anything worthwhile are usually complicated tools. Just pointing that out in case you missed the irony... You make a good point, albeit a very well know point. It's the same kind of point Newton made when he wrote the laws of physics. Everyone since cavemen knew that a falling apple would continue to fall until the ground stopped it from falling. They just did not have the eloquent phrasing of Newton to express the idea in words. You've made the exact same well know expression as Newton. However we do need to explore this subject of broken tools vs unbroken tools a bit more. First let's start by understanding the difference between broken and unbroken editors in the arena of tab width. Tabs Explained: But what IS tab width exactly? Is it a simple unit of measurement like four inches or 22 millimeters, or etc? Well it can be, but for the most part it is something more. Especially in the arena of source code editors! In any plain text editor (i am not speaking of rich text editors or a plain text editor in rich-text mode) where you have only one global font choice at any given time a tab width should be the sum of N glyphs multiplied by the current glyph width. Here is some python code: | glyphW = 10.0 # in milimeters | def set_tab_width(nSpaces): | return glyphW * nSpaces | set_tab_width(1) |10.0 | set_tab_width(10) |100.0 We as humans use numbers of spaces to define a tab width but numbers of spaces is only an abstraction so we don't have to deal with absolute measurements. Fixed Width Fonts: If you are using a fixed-width-font you want the editor to use relative spacing (relative to a glyph width) when defining tab width in spaces. Non Fixed Width Fonts: On the other hand if you use non-fixed-width-font you want the editor to use absolute measurements (since glyphs can be different widths) when defining tab width. Conclusion If your editor does not support as minimum the fixed width version, it is broken. There is NOTHING complicated about creating tab width based on the sum of N glyphs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Dotan Cohen wrote: On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn […] I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. The ambiguity has never been an issue for me. In the unlikely event that an l (el) is in the place of a pipe, the code won't compile and I'll get an error on the line in question. Though that has never actually happened: the IDE is double-checking way before the code gets to the compiler. Zero vs. O (oh), I've never had this issue either and even if one key was hit in place of the other (they are close by) then either the IDE or compiler would catch it, or it would result in a minor bug in a text string. It simply isn't an issue. Apparently it is *has not been* an issue for *you* *yet*. There are languages (like Python) that are compiled just-in-time. Besides, neither an IDE nor a compiler can (always) recognize that foo[b0r] is not foo[bOr] (which really is not a far-fetched example as the O and zero keys are adjacent to each other on in keyboard layouts). You do not want such an ambiguity to bite you later. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:48 pm, Ian Kelly ian.g.ke...@gmail.com wrote: Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. In my mind people are free to use whatever width they like. A tab is a tab is a tab. However for judging line widths we must pick one size tab (since 8 space tabs will create longer lines than four space tabs. This four space mandate is ONLY for determining line width. Let me repeat. ONLY FOR DETERMINING LINE WIDTH. How else could we decide what is truly 80 chars and what is not? -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On Jul 17, 8:49 am, Thomas Boell tbo...@domain.invalid wrote: But why do you enumerate with start=1? Shouldn't you start with index 0? The problem specification says that the the char number should match the emacs goto-char function which is indexed from one, not from zero. This is testable by taking the output of the program and running it through emacs to see that the cursor gets moved exactly to the location of the mismatched delimiter. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:54 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Jul 17, 2011 at 10:29 AM, rantingrick rantingr...@gmail.com wrote: I hate vertical white-space. I follow Python style guide suggestions, and then some! I hate when people insert spaces into code blocks and function/method bodies. If you feel a space must be inserted then that is a good clue you should be using a comment there instead. Vertical breaks should only happen before and after classes, methods, functions, groups of GLOBALS, groups of import statements. Think of func/method bodies as paragraphs and classes as sections of a book. Two vertical spaces between classes and one vertical space between func/methods. You know, there is such a thing as a vertical tab. If we're going to take your suggestion of mandating tabs (for greater freedom!), should we not follow it to its logical conclusion and mandate the usage of vertical tabs instead of multiple newlines? Then everybody could choose for themselves how many lines they want a vertical tab to represent On the face of it one might think vertical tabs are a good idea however newlines work just fine. There is no reason for expanding vertical whitespace to create readble code. If you can offer a good reason i'm listening. Also be sure to post links where others have requested the same. Besides, horizontal tabs are tied closely to distinguishing code blocks. Vertical tabs do not have such a benefit. Instead of vertical tabs we need strict rules on vertical code formatting. I intend to draft AND implement such rules very shortly. It should be MANDATED. And these @holes who refuse to format their code in a community standard will suffer the plague of syntax errors. Who do these people think they are? Do they believe the rules do not apply to them? I'll tell you who they are, they are F'ING format criminals. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, In a programming language yes. You're trying to draw correlations between morality and law. In the arena of programming there is no such thing as morality, only the law. and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. What do you think we have now, a democracy? Does Benevolent?-Dictator- For-Life ring a bell? I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. I can also tell you this. I will not hide under the coat tails of my dev team , NO, i will mingle with the people on my comp.lang.rickpy list. Mats (Ruby's creator) will answer questions on comp.lang.ruby so why does Guido refuse to acknowledge us here on comp.lang.python? -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
Raymond Hettinger wrote: Thomas 'PointedEars' Lahn wrote: Did you notice the excessive crosspost? Please do not feed the troll. IMO, this was a legitimate cross post since it is for a multi-language programming challenge and everyone can learn from comparing the results. Even if so (which I seriously doubt, see also my sig), you cannot reasonably deny that Xah Lee is a well-known Usenet troll, and that this challenge is nothing more than yet another sophisticated attempt at trolling. Please do not feed. PointedEars -- No article in the world is relevant to more than a small handful of groups. If WW III is announced, it will be announced in net.announce.important. -- Peter da Silva, bofh.cabal, Usenet II rules -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:34 pm, Thorsten Kampe thors...@thorstenkampe.de wrote: Indentation alignment will (because you're using only spaces). Otherwise it doesn't align (it can't), simply because of the variable-width. For instance (in a variable-width font): if a == b: var123 = 22 varxyz456 = 333 ^ aligned not aligned Thorsten Tabs will align properly in variable width font if the editor is NOT broken. When displaying a variable width font the editor should switch from using the sum of N glyphs to a user defined total width in absolute measurements (like millimeters). Alternatively if the editor had to guess it could just use the widest glyph of the current set. People, please stop using broken tools. If you stop using them people won't keep producing them. Just imagine how great the world would be if we could convince windows users! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 22:53, Thomas 'PointedEars' Lahn pointede...@web.de wrote: It simply isn't an issue. Apparently it is *has not been* an issue for *you* *yet*. There are languages (like Python) that are compiled just-in-time. Besides, neither an IDE nor a compiler can (always) recognize that foo[b0r] is not foo[bOr] (which really is not a far-fetched example as the O and zero keys are adjacent to each other on in keyboard layouts). You do not want such an ambiguity to bite you later. I do agree that in a weakly-typed language such as python one might conceivably try to use an undeclared variable and the IDE and compiler won't catch that. However 0 vs. O would more likely be 0 vs. o as one would really have to mess up bad to not only press the wrong key but also hit shift at the same time. 0 and o are no harder to distinguish in a VWF than in a FWF. For that matter, why is it assumed that fixed-width fonts by nature better distinguish 0 from O, or any other ambiguous characters? My current system (Kubuntu 11.04, default VWF font in Firefox whatever it may be) distinguished 0 from O just fine. Also I/1 and l/1 are easy to distinguish, but I agree that I/l are not. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
On 07/17/2011 10:16 PM, Thomas 'PointedEars' Lahn wrote: Raymond Hettinger wrote: Thomas 'PointedEars' Lahn wrote: Did you notice the excessive crosspost? Please do not feed the troll. IMO, this was a legitimate cross post since it is for a multi-language programming challenge and everyone can learn from comparing the results. Even if so (which I seriously doubt, see also my sig), you cannot reasonably deny that Xah Lee is a well-known Usenet troll, and that this challenge is nothing more than yet another sophisticated attempt at trolling. Please do not feed. You know what you're doing? You're feeding the troll. Yes, I know Xah Lee. Yes, he is known for trolling. So what? That alone does not mean that every single thing he posts has to be bad. I'm all with Raymond here. There's nothing wrong with this post. This is the one time when it's okay to feed the troll: reinforce good behaviour. -- http://mail.python.org/mailman/listinfo/python-list
Re: a little parsing challenge ☺
Thomas 'PointedEars' Lahn wrote:
It is possible [to parse the parentheses language], with Perl-compatible
Regular Expressions (PCRE), provided that you have enough memory, to use
such an extended Regular Expression (not to be confused with EREs³)⁴:
\((([^()]*|(?R))*)\)
However, even Python 3.2 does not support those expressions (although it
supports some other PCRE patterns, like named subexpressions)⁵, neither do
standard and forked versions of sed(1) (BREs, EREs, using an NFA) nor awk
(EREs, using a DFA or NFA). [That is not to say it would not be possible
with Python, or sed or awk (both of which are off-topic here), but that
more than a Regular Expression would be required.]
Supplemental: Further research shows that the Python `re' module is not
going to implement (PCRE) recursive Regular Expressions. The maintainer's,
Matthew Barnett's, argument (of 2009-03-24) is that such things are better
left to modules such as `pyparsing' [1][2].
However, FWIW, here is the Python port of the start of a language parser
originally written in (and for) ECMAScript:
import re
def matchingBraces(s):
level = 0
for match in re.finditer(r'[{}]', s):
paren = match.group(0)
if paren == {:
level += 1
else:
if level == 0: return False
level -= 1
return level == 0
As you can see, the theoretically necessary PDA¹ implementation can be
simplified to a braces counter with range checks by iterative use of a
Regular Expression. Extensions to meet the challenge are left as an
exercise to the reader.
It has also occurred to me that because parentheses (`(', `)') and brackets
(`[', `]') have special meaning in Regular Expressions (grouping and
character classes, respectively), you could escape all other special
characters in a text and use the RE evaluator itself to find out whether
they are properly nested, having it evaluate one large RE. But I have not
tested this idea yet. (Obviously it cannot be used to satisfy the
challenge's condition that braces – `{', `}' – and other parenthesis-like
characters are to be considered as well, and that the parenthesis-like
characters are to be printed.)
__
¹ Pushdown automaton
References:
[1] http://bugs.python.org/issue694374
[2] http://pyparsing.wikispaces.com/
--
PointedEars
Bitte keine Kopien per E-Mail. / Please do not Cc: me.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 1:54 PM, rantingrick rantingr...@gmail.com wrote: On Jul 17, 1:48 pm, Ian Kelly ian.g.ke...@gmail.com wrote: Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. In my mind people are free to use whatever width they like. A tab is a tab is a tab. However for judging line widths we must pick one size tab (since 8 space tabs will create longer lines than four space tabs. This four space mandate is ONLY for determining line width. Let me repeat. ONLY FOR DETERMINING LINE WIDTH. How else could we decide what is truly 80 chars and what is not? You're so focused on declaring code as compliant or not that you're missing the whole point of having the line width mandate in the first place. It exists so that people using 80-column editors can open up code without having line-wrapping problems. You can arbitrarily declare that line width is to be measured using 4-space tabs, and you can stamp code as being correctly formatted by that metric all you want, but it doesn't change the fact that if somebody with 8-space tabs opens up a file and has to deal with line-wrapping problems, the system has failed them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anders J. Munch wrote: Cameron Simpson wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. Just like in the old days:) Most editors can be configured to do that. Where they fall down, in my experience, is that having inserted those spaces, if you want to delete them you typically have to backspace over them one at a time. I don't enjoy that experience, which is why I have BBEdit Lite set up to use tab-only indentation. If I'm feeling conscientious, I convert to spaces before sharing the code with others. But tabs work better for me given the tools I use and the way I like to work. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 17Jul2011 09:53, rantingrick rantingr...@gmail.com wrote: | On Jul 17, 4:49 am, Anders J. Munch 2...@jmunch.dk wrote: | Originally, tabs were a navigation device: When you press the tab key, you skip | ahead to the next tab column. The notion that whitespace characters are | inserted into the text would have been very alien to someone using text | processing software anno 1970. Same thing with space and enter; on typewriters | the space bar doesn't type anything onto the paper, it moves to the next | column, and that thinking carried over to computers. | | And how much longer are we going to live in the past? Who cares about | backward compatible tabs. Anders was explaining, not supporting-for-the-future. | Mandate the four space tab now! Mandate that | Python takes four space and four space only! We shall lead the charge | for universal tab unity in all programming languages. You really don't know what you're talking about, do you? If Python mandates this (hahaha!) the Perl crowd will immediately move to a more advanced standard, likely 5 space indents (nicely decimalisable) while indenting by two tabs (to flexibly leave room for more intermediate logic to be inserted later with less diff noise, which they will find hard to distinguish from program code). | The reason the tab stop is a full 8 positions: for faster navigation. If it | were 3 positions, it would take forever to skip from the start of line to column | 60. You'd appreciate that, if you were e.g. writing a fiduciary report with | some text to the left and two number columns to the right, back in the day | before spreadsheets and word processor tables. | | Just in case you were not aware this the year 2011. Spreadsheets have | been around for a LONG time. Stop living the past. The past was better. Always was and will be increasingly so in the future. Stop fighting the tide! -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Pardon my driving, I'm trying to reload. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 2:12 PM, rantingrick rantingr...@gmail.com wrote: On the face of it one might think vertical tabs are a good idea however newlines work just fine. There is no reason for expanding vertical whitespace to create readble code. If you can offer a good reason i'm listening. Also be sure to post links where others have requested the same. Okay: 1) Vertical tabs create freedom in the form of user controlled vertical spacing. Vertical spacing height should be a choice of the reader NOT the author. We should never code in vertical spacing height; but that is EXACTLY what we are doing with newlines! No, the reader should be able to choose the vertical spacing height without ANY formatting required or without any collateral damage to the source code. Vertical tabs offer freedom, newlines offer oppression. 2) Vertical tabs remove the need for complicated newline-formatting tools. With vertical tabs only you no longer need those fancy tools to add the correct number of newlines between classes or methods.. THAT IS EXACTLY WHY VERTICAL TABS WHERE INVENTED! Why are we not using this technology? Why are we continuing to promote newlines when vertical tabs are obviously more superior? And as to why we should remove newlines: 3) Using only one vertical space token removes any chance of user error. Unlike many syntactical errors, vertical space is invisible in a text/ source editor. Sure there are tools that can make vertical space visible, however why do we constantly create asinine rules that force us to use complicated tools when we could have choose vertical tabs and none of this would have been a problem? 4) Vertical tabs maintain unity in the source code base. When we replace newlines only with vertical tabs only we maintain a code base that promotes unity and not conformity. There shall not be any inconsistent vertical spacing errors due to mixing vertical tabs and newlines. Also we can avoid adding multiplicity to the compiler. The compiler will not have to consider BOTH vertical tabs AND newlines as valid vertical spacing tokens, only vertical tabs. The logic would be much simpler. Besides, horizontal tabs are tied closely to distinguishing code blocks. Vertical tabs do not have such a benefit. Instead of vertical tabs we need strict rules on vertical code formatting. I intend to draft AND implement such rules very shortly. Vertical spacing helps to visually separate classes from other classes, and methods from other methods. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, In a programming language yes. You're trying to draw correlations between morality and law. In the arena of programming there is no such thing as morality, only the law. You have been drawing the same correlation from your very first post where you stated, Tabs offer freedom, spaces offer oppression. and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. What do you think we have now, a democracy? Does Benevolent?-Dictator- For-Life ring a bell? I don't see Guido going around making ridiculous pronouncements about what forms of indentation are acceptable (beyond the standards that are set and expected for the standard library, that is). He could have made the language space-only from the very beginning. He didn't; that should tell you something. He also could have insisted that the parser only accept source written in the ISO-8859-1 encoding for unity and freedom, but he didn't. Or he could have stated absolute imports only from the very beginning, and yet even in Python 3 where the old-style relative imports have been removed, relative imports are still available to be used. I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. Thanks, but I won't be needing a voice, because your version of Python will clearly be too limiting from the ground up for me to have any interest in using it in the first place. I can also tell you this. I will not hide under the coat tails of my dev team , NO, i will mingle with the people on my comp.lang.rickpy list. Mats (Ruby's creator) will answer questions on comp.lang.ruby so why does Guido refuse to acknowledge us here on comp.lang.python? Probably for the same reason that (I presume) he doesn't spend all day answering Python questions on stackoverflow or responding to comments about Python on slashdot: he can get more done in his actual job by unsubscribing. If you want to have input on Python, all you have to do is subscribe to python-dev. Of course, it *is* a moderated list, so if you make as much of a nuisance of yourself over there as you do here, they might kick you out. -- http://mail.python.org/mailman/listinfo/python-list
Crazy what-if idea for function/method calling syntax
Jumping in: What if a construct xx(*args1, **kwargs1)yy(*args2, **kwargs2) was interpreted as xxyy(*(args1+args2), **(kwargs1+kwargs2)) (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the order given”, since dicts can't be added) This construct is currently a syntax error. The intent of this idea is to help improve legibility. Example: def place_at(item, x, y): blah blah could be called as place(item)_at(x, y) I believe it makes code more readable; it's also a more terse alternate to a call like: place_at(item=item, x=x, y=y) Another example: group(iterable)_by(callable) I can think of some objections myself; the most important is whether the current parser (with a complexity defined by the wishes of Guido, which I faintly recall reading about a long time ago) can do that or not. I also don't know if any other language exists supporting this construct. There is also a big window for misuse (i.e. break the function/method name in illogical places), but I would classify this under “consenting adults”. It might be suggested as good form that function names break at underscores, like my examples. I know it seems extreme. I only posted this idea here because I would like some input about how feasible it can be and whether people like it or not. Any input is welcome; however, I kindly request that negative replies include counter-arguments (an abrupt “no” or “yuck!” does not help others improve their knowledge of Python or Pythonic- ness :). Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 03:12 PM, rantingrick wrote: I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. That reminds me of Full Metal Jacket. Here you are all equally worthless. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI22xAAoJEPiOA0Bgp4/LIwsIANrgRO1m4f2w4M6HQ0I2Ysjl SqSCQ4r4p7ZG4O6t/ms6r3uVQXh7FrV1atkWLkUprwd+DfPTl2Lpp5xF7RB2lJ4/ pvcIWQ47kC2F4BgbcW2UN8E1vu6K1G+q/s81HzXsTfdnFqYBrhli+Hd3XvgFH9Zr nt8dKJuX1lVowYeg22iZyUiMaubpZl35Xyw4xFTPJ7eW8ynHriYG3JfJtUVjDYz0 Hs4oXrdcllugOwYcGUN4tddJ1uls/Xat16HUtxOIYIJUQr1kZVa/l0kmsoi1AT1/ SBCnLzyiuBLA8fHcvE675+/834FZi9sgAPOM4HY/dx3YDa8musSjbPtfSUFAQKQ= =NEuJ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Crazy what-if idea for function/method calling syntax
On 07/18/2011 12:54 AM, ΤΖΩΤΖΙΟΥ wrote: Jumping in: What if a construct xx(*args1, **kwargs1)yy(*args2, **kwargs2) was interpreted as xxyy(*(args1+args2), **(kwargs1+kwargs2)) (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the order given”, since dicts can't be added) This construct is currently a syntax error. The intent of this idea is to help improve legibility. Example: def place_at(item, x, y): blah blah could be called as place(item)_at(x, y) Objective C does something similar. I don't actually know Objective C, but from what I remember from when I briefly read up on in (somebody please correct me), that call could, in Objective C, look something like: [ place:item atPositionX:x Y:y ] The idiomatic Python way for this is the following: def place(item, at): pass place(item, at=(x,y)) Your suggestion would open up an infinite number of different, mostly unreadable, ways to call a single method. This completely goes against the principle of encouraging there being only one way to do things. Multi-part method names (with fixed, non-optional, split points, if you know what I mean) are slightly interesting, but don't fit in, and, more importantly, don't add anything to the language: all the possible readability benefits are already provided (and trumped) by keyword arguments. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 11:46 AM, rantingrick wrote: Why do you feel the need to layout your code in a GUI-listview manner. Next you'll want column titles and column sorting... Jeez! This is what you should have done... I was testing my psychic abilities. I had the feeling that such a layout would irritate you, so I had to try it. Before, I thought this psychic stuff was all hokey, but now... - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI25rAAoJEPiOA0Bgp4/L5lwIAIxwvAz7QBEOaQ9Hn/Er7esE t4A76iJMOzVajFD61Wf8HkCyBrkQPk2i7koUqByUbQMRjAD3ukBorH+RNlfYwdJQ w2HGjxCG36fA9yYZe5N+ySX1UlxH4pbZJLDxJMvo4brF8XVVOknsQyIW3rPM2ma9 CtdP4pWRpuE+4mz+wu4uxZW0xFarFV64TbcsXs1aZZAUSSJ4HUEbSuk/gw4IGBc5 HrOCBKt9hlgB7oh6KyITikFHCWV63iDzqfkVxP7Cr7ON3KaMPcfEVe2JowZv8NeV cZmr4pbxWQ+ya0i8ukGjizrUa+Jdjp0p3I1OsVlZ0NCLyp4v5zDVS6R+97zjVc4= =lBEF -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 06:29 PM, Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I think the reason the idea isn't dead is because of the emergence of new devices with small displays (tablets/smartphones/etc.) and their increasing popularity. When writing code that is meant to be run on desktops or servers, the 80-column limit is mostly irrelevant, but Python running on these small devices, especially with Python code being interpreted rather than compiled, it's convenient to edit code on those platforms, where there is a significant column limit. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI3aPAAoJEPiOA0Bgp4/LRMQH/irglKlq7+Nk67dvGuQt39ZH nHqEE4HG5J7y/JfW+3g4UbhISHFwsJO0yvvcUN8cfLQ9O4KxzR65PS6Jqs8KEWS+ 04hAZl0AbEKHZv3nOxWhxvAF5saJnq0xWHAtE9tFwS31I7Oh65rCBZD4g9BFiCql YeTAklPB64Ik6F+7kcLDx3xDn6CPb/03Nj2assGatSUEY5p0OqzZ9nPnBxifLDFC piOkZOgPW39s/zEzr+0LiD3ayFmtPoYldBFR0c7qkzyN6aS+Fur4kqbxlGl4jbI/ Xkms/5yrie/jAf4HgcaMHX2l4Or/dY7jyb6cK+How+yNa76xh6CZdxIZ68oR6Fs= =K9SY -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
In article mailman.1196.1310946970.1164.python-l...@python.org, Andrew Berg bahamutzero8...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 06:29 PM, Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I think the reason the idea isn't dead is because of the emergence of new devices with small displays (tablets/smartphones/etc.) and their increasing popularity. When writing code that is meant to be run on desktops or servers, the 80-column limit is mostly irrelevant, but Python running on these small devices, especially with Python code being interpreted rather than compiled, it's convenient to edit code on those platforms, where there is a significant column limit. Can you give me a more specific example? I assume there's nobody (at least nobody sane) editing Python source code on iPhones. I'll admit I'm not that familiar with the plethora of tablets and handheld devices out there. Are there really devices which impose exactly an 80-column width? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 07:28 PM, Roy Smith wrote: Can you give me a more specific example? I assume there's nobody (at least nobody sane) editing Python source code on iPhones. I haven't done it myself, but there are plenty of Python projects out there made for mobile devices, and I would imagine the convenience of editing on the platform itself to test things immediately outweighs the inconvenience of a small display and tiny keyboard. Are there really devices which impose exactly an 80-column width? Font size can be changed, so it's not a matter of a fixed number of characters, but rather how many characters can fit on such a small display at a reasonable size. My guess is that 80 is pretty arbitrary nowadays, but it's much easier to stick with 80 than debate over it, especially when display sizes vary so greatly among these devices. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4LnAAoJEPiOA0Bgp4/L9s4H/1hZUtzSUEK3ZCs/+5SQk4dE W7Au9Gv4rpNK6zmIRTmWkBeqUZdJHVXftQslnkvVr+pUMjz395YZbT3a2rAiaMje IYq2HqKk8kZAeVo1sQLlKAl5PcCP8yJKGW1UJBLcLarXC33e/3pB1M7MY3QIVEta S68IsBR5RJdtNIOJcmNtYEglPe1CSXt0LeEGYoseBhz9UyUDnnJlelu6WRAatKxR jB8sbaWN4wLdT1iFkNFePSA1hJQSGmot0D5UaYTTG5HuG4JNlSeTZ23ctFLph/XG 96vndHBjxkDEdzCBkxSRaM5i5W/vSa/t25c5uDvXibldrxBWqm2QYJTeMhJ9JsY= =6RXz -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4NvAAoJEPiOA0Bgp4/LI8UH/3s+YyOsRGfHmcfX17glGUPT bMAHq7vkmyWp5/zdcTWiRSxySrmTdcBJlquQOzUXhzGjRJlDoRQJrVypNr5zEO/r FQkqwSnd0MmAg7wQX5I8xnM+muqeqOMvSqPs6HzBUiUqgwNoMlDn1v0Cc0h72mxx Nf5r67/0Sptg7sR15aZnLtDodfql6qDxbIbDBdsp6SVnL6XE3l2NfFnB8DcOXRXk 2ooiV5/HlV0S2lr5TiKshyWuumQCnOPg6+ZDc//vev4L3aeM6EAXtYTWTWJEERl+ 6PMP6u1SmA7P43jjzunxTiyXRkLLp7lJDaoWVzb3o+FDLOwNhgVEUH28TiXuNgQ= =0HaP -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Chris Angelico wrote: On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. Put your money - or, in this case, development time - where your big ranting mouth is. Prove that your ideas are worth something by acting on them. Ha ha, oh that's hilarious!!! Back in 2007, a n00b calling himself TheFlyingDutchman who I am *reasonably* sure was Rick decided to fork Python: http://mail.python.org/pipermail/python-list/2007-September/1127123.html Then in 2010, Rick promised that if the Python developers didn't bow to his demands, he would folk Python, and the silent majority who agreed with him but were too terrified to say so publicly would drop CPython in a flash and follow him. Thread starts here: read and weep. http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227 How's that fork going Rick? Written a single line of code yet? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg wrote: I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. There's a mailing list for Python scripting on Android -- List-Subscribe: http://groups.google.com/group/python-for- android/subscribe?hl=en_US, mailto:python-for- android+subscr...@googlegroups.com . Tends to be pretty detail-oriented. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg wrote: I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. There's a mailing list for Python scripting on Android -- List-Subscribe: http://groups.google.com/group/python-for- android/subscribe?hl=en_US, mailto:python-for- android+subscr...@googlegroups.com . Tends to be pretty detail-oriented. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Sorry, that looks like a troll, but isn't. I seriously do set my editor to a soft limit of 78 characters. That is, I can exceed it if I want, but almost never do. Why 78? Because it's one less than 79, as mandated by PEP 8, and two less than 80, the hoary old standard. The reasons given in PEP 8 for 79 make sense to me, and I don't like reading really long lines of code. With one exception, if your line of code needs more than 79 plus or minus 1 characters, chances are it is doing too much. The exception is, you have an indented block of code, perhaps three or four indents deep (surely you never allow anything to get beyond five or six indents?), and you want to raise an exception: raise SomeExceptionType(and here's a rather long error message blah blah blah) If I only go a character or two over, I might be tempted to just go over. But normally I split the line, as above, and use implicit line concatenation. http://www.python.org/dev/peps/pep-0008/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 07:54 PM, Steven D'Aprano wrote: Then in 2010, Rick promised that if the Python developers didn't bow to his demands, he would folk Python, and the silent majority who agreed with him but were too terrified to say so publicly would drop CPython in a flash and follow him. Thread starts here: read and weep. http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227 How's that fork going Rick? Written a single line of code yet? I skimmed through the first post a bit and it's hilarious. TL;DR for now, but I'll read the whole thread later. I'm still surprised how much entertainment I get from a programming language newsgroup. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4vQAAoJEPiOA0Bgp4/LiN4IAMFXmBUxLOr1lYRIVY7kSwWj Ln+pTvOR6S0og6S1v1fljTeFy8NWsbeLHjF48TahJf5VlEqiuCd7zUQ8r0gDn6ut +ibDz+rtJJAE2XOG5myBylwcuG31TuaoXcSsNMCTnIMi6ZsoOWeBmkD0rvG66eFM tPaceBdv7qe/0oNcy/DalEZ8gE2NSfrm6u4g5RQge8E4o4IwCWwMdSOkKRjkJdix mbCfcCytQtc+X7IFwuUcFMAtFq9f8rzp8Jl45/wCBlxBPvZbLfqJvit9J8hgF81v KgSeyV9BLKgzRamBOZQdG2/mUwJV8aQwxdSJrtRwZ0YWpQaOPnTZlQsRyAzf4nw= =9zSp -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: The exception is, you have an indented block of code, perhaps three or four indents deep (surely you never allow anything to get beyond five or six indents?), and you want to raise an exception: raise SomeExceptionType(and here's a rather long error message blah blah blah) Give yourself plenty more room, stay within PEP 8, *and* make the alignment robust in the face of changes:: raise SomeExceptionType( and here's a rather long error message blah blah blah) -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Argparse, and linking to methods in Subclasses
Hi,
I have a simple Python script to perform operations on various types on
in-house servers:
manage_servers.py operation type_of_server
Operations are things like check, build, deploy, configure, verify etc.
Types of server are just different types of inhouse servers we use.
We have a generic server class, then specific types that inherit from that:
class Server
def configure_logging(self, loggin_file):
...
def check(self):
...
def deploy(self):
...
def configure(self):
...
def __init__(self, hostname):
self.hostname = hostname
logging = self.configure_logging(LOG_FILENAME)
class SpamServer(Server):
def check(self):
...
class HamServer(Server):
def deploy(self):
...
My question is how to link that all up to argparse?
Originally, I was using argparse subparses for the operations (check, build,
deploy) and another argument for the type.
subparsers = parser.add_subparsers(help='The operation that you want to run on
the server.')
parser_check = subparsers.add_parser('check', help='Check that the server has
been setup correctly.')
parser_build = subparsers.add_parser('build', help='Download and build a copy
of the execution stack.')
parser_build.add_argument('-r', '--revision', help='SVN revision to build
from.')
...
parser.add_argument('type_of_server', action='store', choices=types_of_servers,
help='The type of server you wish to create.')
Normally, you'd link each subparse to a method - and then pass in the
type_of_server as an argument. However, that's slightly backwards due to the
classes- I need to create an instance of the appropriate Server class, then
call the operation method inside of that.
Any ideas of how I could achieve the above? Perhaps a different design pattern
for Servers? Or a way to use argparse in this situation?
Thanks,
Victor
--
http://mail.python.org/mailman/listinfo/python-list
