Re: Newbie question. Are those different objects ?
On Friday, December 20, 2013 9:30:22 PM UTC+5:30, Mark Lawrence wrote:
> On 20/12/2013 15:34, rusi wrote:
> > On Friday, December 20, 2013 8:46:31 PM UTC+5:30, dec...@msn.com wrote:
> >> y = raw_input('Enter a number:')
> >> print type y
> >> y = float(raw_input('Enter a number:'))
> >> print type y
> >> I'm assuming that y is an object. I'm also assuming that the second and
> >> the first y are different objects because they have different types.
> > You are also assuming that the two horizontal lines sometimes called
> > 'equals'
> > have something to do with something called by the same name in math --
> > equations
> A good point. Shall I write a PEP asking for a language change which
> requires that that stupid = sign is replaced by a keyword reading
> something like
> thenameonthelefthandsideisassignedtheobjectontherighthandside ?
Good idea. Only you were beaten to it by about 2 decades.
The language ABC calls it 'put' and corrects the unnecessary gratuitous
right to left order.
Reference
http://homepages.cwi.nl/~steven/abc/qr.html#COMMANDS
Examples
http://homepages.cwi.nl/~steven/abc/types.html
And what does that have to do with python?
http://www.onlamp.com/lpt/a/2431
--
https://mail.python.org/mailman/listinfo/python-list
Re: Newbie question. Are those different objects ?
On Friday, December 20, 2013 8:46:31 PM UTC+5:30, dec...@msn.com wrote:
> y = raw_input('Enter a number:')
> print type y
> y = float(raw_input('Enter a number:'))
> print type y
> I'm assuming that y is an object. I'm also assuming that the second and the
> first y are different objects because they have different types.
You are also assuming that the two horizontal lines sometimes called 'equals'
have something to do with something called by the same name in math -- equations
Lets unassume that and rewrite the code
1. y ! raw_input('Enter a number:')
2. print type y
3. y ! float(raw_input('Enter a number:'))
4. print type y
Now read that 1 as first, 2 as second etc and read the '!' as 'MAKE'.
(It may help to shout it)
Now what was your question?
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to use the method loadtxt() of numpy neatly?
On Friday, December 20, 2013 11:18:53 AM UTC+5:30, chao dong wrote:
> HI, everybody. When I try to use numpy to deal with my dataset in the style
> of csv, I face a little problem.
> In my dataset of the csv file, some columns are string that can not
> convert to float easily. Some of them can ignore, but other columns I need to
> change the data to a enum style.
> for example, one column just contain three kinds : S,Q,C. Each of them
> can declare one meaning, so I must convert them to a dict just like {1,2,3}
What does "dict like {1,2,3}" mean??
On recent python thats a set
On older ones its probably an error.
So you can mean one of:
1. Set([1,2,3])
2. List: [1,2,3]
3. Tuple: (1,2,3)
4. Dict: {"S":1, "Q":2, "C":3}
5. An enumeration (on very recent pythons)
6. A simulation of an enum using classes (or somesuch)
7. Something else
> Now the question is, when I use numpy.loadtxt, I must do all things above
> in just one line and one fuction. So as a new user in numpy, I don't know how
> to solve it.
I suggest you supply a couple of rows of your input
And the corresponding python data-structures you desire
Someone should then suggest how to go about it
--
https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
> On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote: > > rusi wrote: > > > Soon the foo has to split into foo1.c and foo2.c. And suddenly you need > > > to > > > understand: > > > 1. Separate compilation > > > 2. Make (which is separate from 'separate compilation') > > > 3. Header files and libraries and the connection and difference > > It's pretty common here to have people ask questions about how import > > works. How altering sys.path effects import. Why is import not finding > > my module? You quickly get into things like virtualenv, and now you've > > got modules coming from your source tree, from your vitualenv, from your > > system library. You need to understand all of that to make it all work. > Yes agreed. Python is far from stellar in this regard. > Just as distutils got into the core at 2.3(??) now at 3.3 > virtualenv(+pip+wheel) > is getting in. Belated but better late than never. > > None of that is specific to C. Virtually any language (including > > Python) allows a program to be split up into multiple source files. If > > you're running all but the most trivial example, you need to know how to > > manage these multiple files and how the pieces interact. > Thats a strange thing to say. In the abstract every language that > allows for significant programs supports separate units/modules. > Somewhere those units will map onto system entities -- usually though > not always files (think of PL-SQL inside Oracle). > Even assuming files, the lines drawn between interior (to the language) > and exterior (OS-facing) are vastly different. > C, Pascal, Python, Java, SML, APL -- all very different in this regard. Just adding this: Different languages do their modularizing and packaging differently (what I earlier said) in order to achieve different tradeoffs. Here's a thread by a competent programmer who switched from Lisp to C++. https://groups.google.com/forum/#!topic/ledger-cli/Mjky9AvrRKU He clearly says that while he loves Lisp the language, its packaging facilities lost out to C++ and so he rewrote his whole app in C++. -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Thursday, December 19, 2013 10:20:54 AM UTC+5:30, Mark Lawrence wrote: > On 19/12/2013 04:29, rusi wrote: > > On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote: > >> On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote: > >>> The only issue for me was to figure out how to do in C what I already > >>> knew in Pascal. And I had to waste a *lot* more time and mental effort > >>> to mess with that language than it took for me to learn *both* the > >>> basics of programming per se *and* Pascal in the first class at my home > >>> university. > >> It's sounds like you made, and are carrying on making, one of the classic > >> mistakes of software engineering: you're trying to write one language in > >> the style of another. It is possible to write C code as if it were > >> Pascal, but it's a painful process and it won't be pretty. It's far > >> better to use a language as it is rather than as you want it to be. > > Yes but the reverse is also true: Sometimes the best code in language > > L is first conceptualized in design-language D and then 'coded' into > > L. > > When we were students D was called 'flow-charts' > > Gone out of fashion today and replaced by UML. > > Now I expect the majority on this list to not care for UML. > > However the idea of a separate design language is not negated by the fact > > that UML is overkill and silly. > > eg Saw this (on the Erlang mailing list) > > In some Australian university (in the 90s) 2 sems of Cobol was > > replaced by 1 sem Scheme + 1 sem Cobol. Students learnt more Cobol in > > the second arrangement than in the first. [Note: 'More Cobol' not 'More > > Programming'] > > Now if you were to ask those *students* I would expect similar > > emotions towards Cobol as Wolfgang is expressing towards C. > > That is however a separate issue :D > If C is such a crap language, what does it says for the thousands of > languages that never got anywhere? Or did C simply have a far larger > sales and marketing budget? :) Are you addressing that to me? [Assuming you are a good boy who does not use GG-crap and knows the laws of snipping and attributing I am taking it so :D ] No I am not in the 'C-is-crap' camp. Very far into the opposite actually. What would you say to someone who says: - food is crap to eat - air is crap to breathe "C is crap technology" is analogous. If you are using python its likely CPython. Whats the C there? If you are connected to the net the modem likely runs a linux. Coded in? I am an Luddite -- dont touch computers. Right. The car I drive probably has embedded chips... Embeded linux. No Amish/Luddite is not enough to say "No!" to C You'd have to be completely isolated from every connection with modern civilization. So python programmers employ the 'black-cat' squad of GvR and gang to shield us from C. Because they are good at it we can afford to ignore it. No, "No C" is no option. The only option is at how many removes we keep away from it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Thursday, December 19, 2013 9:46:26 AM UTC+5:30, Roy Smith wrote: > rusi wrote: > > Soon the foo has to split into foo1.c and foo2.c. And suddenly you need to > > understand: > > 1. Separate compilation > > 2. Make (which is separate from 'separate compilation') > > 3. Header files and libraries and the connection and difference > It's pretty common here to have people ask questions about how import > works. How altering sys.path effects import. Why is import not finding > my module? You quickly get into things like virtualenv, and now you've > got modules coming from your source tree, from your vitualenv, from your > system library. You need to understand all of that to make it all work. Yes agreed. Python is far from stellar in this regard. Just as distutils got into the core at 2.3(??) now at 3.3 virtualenv(+pip+wheel) is getting in. Belated but better late than never. > None of that is specific to C. Virtually any language (including > Python) allows a program to be split up into multiple source files. If > you're running all but the most trivial example, you need to know how to > manage these multiple files and how the pieces interact. Thats a strange thing to say. In the abstract every language that allows for significant programs supports separate units/modules. Somewhere those units will map onto system entities -- usually though not always files (think of PL-SQL inside Oracle). Even assuming files, the lines drawn between interior (to the language) and exterior (OS-facing) are vastly different. C, Pascal, Python, Java, SML, APL -- all very different in this regard. -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Thursday, December 19, 2013 6:19:04 AM UTC+5:30, Rhodri James wrote: > On Tue, 17 Dec 2013 15:51:44 -, Wolfgang Keller wrote: > > The only issue for me was to figure out how to do in C what I already > > knew in Pascal. And I had to waste a *lot* more time and mental effort > > to mess with that language than it took for me to learn *both* the > > basics of programming per se *and* Pascal in the first class at my home > > university. > It's sounds like you made, and are carrying on making, one of the classic > mistakes of software engineering: you're trying to write one language in > the style of another. It is possible to write C code as if it were > Pascal, but it's a painful process and it won't be pretty. It's far > better to use a language as it is rather than as you want it to be. Yes but the reverse is also true: Sometimes the best code in language L is first conceptualized in design-language D and then 'coded' into L. When we were students D was called 'flow-charts' Gone out of fashion today and replaced by UML. Now I expect the majority on this list to not care for UML. However the idea of a separate design language is not negated by the fact that UML is overkill and silly. eg Saw this (on the Erlang mailing list) In some Australian university (in the 90s) 2 sems of Cobol was replaced by 1 sem Scheme + 1 sem Cobol. Students learnt more Cobol in the second arrangement than in the first. [Note: 'More Cobol' not 'More Programming'] Now if you were to ask those *students* I would expect similar emotions towards Cobol as Wolfgang is expressing towards C. That is however a separate issue :D -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Thursday, December 19, 2013 7:10:53 AM UTC+5:30, Roy Smith wrote: > Grant Edwards wrote: > > I've always felt that there are features in C that don't make a lot of > > sense until you've actually implemented a compiler -- at which point > > it becomes a lot more obvious why some thing are done certain ways. > Example? > I suspect what you mean is, "There are some things that don't make sense > until you understand computer architecture". One way of rephrasing what Grant is saying is: "You cannot be a C programmer without being a system programmer" This certainly includes machine (hardware) architecture. But it includes much else besides, which can generally be subsumed under the rubric "toolchain" A python programmer can write foo.py and run: $ python foo.py A C programmer writes foo.c and has to run the sequence: $ gcc foo.c $ a.out So far the difference looks minimal. However it does not stop here. Soon the foo has to split into foo1.c and foo2.c. And suddenly you need to understand: 1. Separate compilation 2. Make (which is separate from 'separate compilation') 3. Header files and libraries and the connection and difference Now if youve taught a few classes you will know what a hell each of these is. In particular, every C teacher struggles with: "stdio.h is the standard library" And all this has not yet touched the labyrinths of linker errors with the corresponding magic spells called ranlib, nm etc Got past all this kid-stuff? Now for the Great Initiation into Manhood -- autoconf So... Is all this core computer science? Or is it the curiosities of 40 year old technology? -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Wednesday, December 18, 2013 8:53:54 PM UTC+5:30, Ethan Furman wrote: > On 12/18/2013 12:18 AM, Steven D'Aprano wrote: > > On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote: > >> On Wed, 2013-12-18 at 01:33 +, Steven D'Aprano wrote: > >>> On 12/17/2013 04:32 PM, Roy Smith wrote: > You never have to wonder what the > lifetime of an object is, > >>> Since C isn't object oriented, the lifetime of objects in C is, um, any > >>> number you like. "The lifetime of objects in >>> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously > >>> true statement. > >> The implication that only an "object oriented" language could have a > >> concept of object lifetimes is false. > > Only object-oriented languages have *objects*. C does not have objects, > > it has values. > The word 'object' has many more meanings than the one implied by Object > Oriented Programming, as you well know. > > And yes, I'm being pedantic. > No, you're being an ass. Is this discussion REALLY happening...??? In a non-programmer/layman forum it would be completely normal However given that we are supposedly a programmer list I am incredulous Here is some innocuous looking python code: A> def draw_helper(canvas, level, p1, p2, p3): if level == 1: canvas.create_polygon(p1, p2, p3) else: p4 = midpoint(p1, p2) p5 = midpoint(p2, p3) p6 = midpoint(p1, p3) draw_helper(canvas, level - 1, p1, p4, p6) draw_helper(canvas, level - 1, p4, p2, p5) draw_helper(canvas, level - 1, p6, p5, p3) And here is what happens when you run it B> http://homes.cs.washington.edu/~reges/python/sierpinski8.png (More here http://homes.cs.washington.edu/~reges/python/) Can you really say that what you see in B you can infer from A WITHOUT RUNNING IT?? The above is the subject that is technically called 'complexity' in math terms. If we allow the term 'complex' to be more general (like the argument about 'object') then this becomes the pain and beauty, the mystery and horror of programming -- seemingly trivial code when seen as a PROGRAM can endlessly evolve into unimaginable complexity when elaborated into a PROCESS. So when Chris/Roy are talking of the simplicity of C's lifetime rules they are talking of the primitive building blocks to make and understand program-texts. And when Steven/Devin are talking of the complexity of the same they are talking of the arcane results that emerge when those programs run. And from here its a small step to understand why python's slightly more complicated semantics result in so much less complexity than C's seemingly simple rules: C has a double complexity generator -- stack + heap vs python only having a 'managed' heap. Analogously if the Sierpinsky triangle above were flattened into 1-d there would be nothing to note about it. Like python: Boring 'weenie' language... Never segfaults -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 17, 2013 4:42:07 PM UTC+5:30, Oscar Benjamin wrote: > On 17 December 2013 00:39, rusi wrote: > > I had a paper some years ago on why C is a horrible language *to teach with* > > http://www.the-magus.in/Publications/chor.pdf > Thanks for this Rusi, I just read it and it describes very well what I > think about our own C course. My choice quote from the beginning would > be "When the irrelevant becomes significant, the essentials become > obscured and incomprehensible." > (BTW is there any reason that the document is repeated twice in the same pdf?) Thanks for the heads-up -- some pdf generation issues I guess Is it ok now? Yeah I could clean up some more formatting some more but its 25 years now and Ive forgotten my troff!! More important the tone is not what I would use today. The point I was trying to make then was: C is an unsuitable language to TEACH PROGRAMMING WITH because it fills students' brains with irreleventia Once one knows the stuff, C is a NEAT programming language. IOW its a question of learning-curve not the content. -- https://mail.python.org/mailman/listinfo/python-list
Re: Logger module in python
On Wednesday, December 18, 2013 8:52:11 AM UTC+5:30, smileso...@gmail.com wrote: > Hi, > I am a newbie in python. I am looking for a existing module which I can > import in my program to log the objects to a file? > I know there is a module Data::Dumper in perl which dumps the objects to > file. But not sure about python. Assuming you are looking for a serialization format: If efficiency, easily-at-hand, standard are important then pickle better than json better than yaml If however readability of the output (as the word 'log' suggests) is desired its the other way round: yaml is the most readable, pickle is utterly unreadable -- https://mail.python.org/mailman/listinfo/python-list
Re: seeking a framework to automate router configurations
On Wednesday, December 18, 2013 8:10:20 AM UTC+5:30, Frank Cui wrote: > Hi Pythoners, > I'm looking for a tool or framework in which I can do a slight modification to > achieve the following task: > "Asynchronously reset a large number of cisco routers back to their original > configurations and push prepared initial configurations to them" > I did find some similar existing work such as exscript and trigger, however > I was stuck in the following two problems : > 1. telneting to a non-default port number (other than 23) > 2. handling of customized banner messages. > can you give some hints on this ? For the low level details (exscript/trigger) I dont know. However for the higher level organization issues you may want to look at 1. cuisine http://stackful-dev.com/cuisine-the-lightweight-chefpuppet-alternative which uses 2. fabric http://docs.fabfile.org/en/1.8/ And maybe 3. tox http://tox.readthedocs.org/en/latest/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 17, 2013 8:21:39 PM UTC+5:30, Neil Cerutti wrote: > On 2013-12-17, Steven D'Aprano wrote: > > I would really like to see good quality statistics about bugs > > per program written in different languages. I expect that, for > > all we like to make fun of COBOL, it probably has few bugs per > > unit-of-useful-work-done than the equivalent written in C. > I can't think of a reference, but I to recall that > bugs-per-line-of-code is nearly constant; it is not language > dependent. So, unscientifically, the more work you can get done > in a line of code, then the fewer bugs you'll have per amount of > work done. Enter the (One-Liner) Dragon! http://www.youtube.com/watch?v=a9xAKttWgP4 -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python, Help to get script working?
On Tuesday, December 17, 2013 4:35:31 PM UTC+5:30, Mark wrote: > I am sorry, using google groups i cant tell what you see... > Anyways, I guess i will just make lots of lines instead of long sentences? > How about this, the first person that can get this to work for me... > I will paypal them 20 dollars for helping me. > I just want to get this thing up and going. > Ive posted where i am having trouble and got 2 replies talking about > spacing... > and not fixing any issues or giving advice. > Either that or somebody who thinks they might be able to help, can you plz > reply? I believe you were given a suggestion by Steven on posting a traceback Did you follow that? (Genuine question!!) Because if you did and it got lost in the characteristic 'GG-crap' you would not know that it had been 'crapified' by GG and others would not know that there was anything to read in the mess. So... assuming youve understood the following: 1. Read and follow https://wiki.python.org/moin/GoogleGroupsPython 2. Read and follow Steven's advice on how to ask help especially regarding errors 3. Try to minimize external links to code especially small snippets maybe best to just start a new thread??? -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 17, 2013 9:51:07 PM UTC+5:30, larry@gmail.com wrote: > On Tue, Dec 17, 2013 at 10:35 AM, Mark Lawrence wrote: > > I was in charge of the team at work that had to make all code Y2K compliant. > > I discovered the one bug that to my knowledge slipped through the net. Four > > years later back at the same place on contract I fixed the fix!!! > > From around 1997 till 2000 all I did was fix Y2K bugs. I'm pretty > > sure I got them all. For one client I fixed well over 200. After > > the new > year came and nothing broke, the owner of the company > > said "You made > such a big deal about this Y2K stuff, and it > > turned out not to be a > problem at all." Hahaha -- Very funny and serious. Ive been actually experienced being kicked out of job for writing decent working code and not making a big deal of it. Comes back the start of the thread -- What do we teach students? Should we teach how to write the best possible code and as effortlessly as possible? Or should we also teach how to make a fuss, how to pretend to (over)work while actually (under)delivering? In a Utopia this would not be a question at all. But we dont live in Utopia... [And there are languages WAY better than C... C++ for example] -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 17, 2013 6:14:59 AM UTC+5:30, Chris Angelico wrote: > On Tue, Dec 17, 2013 at 11:39 AM, rusi wrote: > > I had a paper some years ago on why C is a horrible language *to teach with* > > http://www.the-magus.in/Publications/chor.pdf > > I believe people did not get then (and still dont) that bad for > > - beginner education (CS101) > > - intermediate -- compilers, OS, DBMS etc > > - professional software engineering > > are all almost completely unrelated > Yes. In esr's essay on becoming a hacker[1] he says: > """There is perhaps a more general point here. If a language does too > much for you, it may be simultaneously a good tool for production and > a bad one for learning.""" There is this principle by Buchberger called the "Black-box White-box principle" Unfortunately I can only find mathematicians talking about it http://www.math.rutgers.edu/~zeilberg/Opinion65.html and no CS-ists/programmers. eg To teach OS, minix is better than linux To use, linux is better FreeBSD may be a good middle point. It may also be a bad middle point -- practically too hard to use or study. Which is why in practice separating teaching tools from professional ones is better than thrashing about using the same for both > Definitely true, though I think it has exceptions. > [1] http://www.catb.org/esr/faqs/hacker-howto.html Yeah As esr says python is an exception And even here as it progresses it becomes more professional and less educational -- https://mail.python.org/mailman/listinfo/python-list
Re: New to Python, Help to get script working?
On Tuesday, December 17, 2013 1:55:57 AM UTC+5:30, Mark wrote: > I am sorry if the way I posted messages was incorrect. Like I said, I am new > to google groups and python quite a bit but i am trying to do things > correctly by you guys. The errors that I am getting were not necessarily > posting traceback messages. Thats better -- thanks You still need to go through https://wiki.python.org/moin/GoogleGroupsPython See the length of your "I am sorry..." line above -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Saving binaries in a specific way
On Tuesday, December 17, 2013 5:00:14 AM UTC+5:30, Djoser wrote: > Basically I have a .dat file, so I get some numbers and make a different > conversion. > > I'll try this struct script. I'm not used to it, but it seems to do what I > want. Construct is a very powerful utility for binary parsing and building https://pypi.python.org/pypi/construct http://construct.readthedocs.org/en/latest/ Though for your currently stated purpose struct should be enough -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 17, 2013 5:58:12 AM UTC+5:30, Ned Batchelder wrote: > On 12/16/13 3:32 PM, Wolfgang Keller wrote: > >>> And ever after that experience, I avoided all languages that were > >>> even remotely similar to C, such as C++, Java, C#, Javascript, PHP > >>> etc. > >> I think that's disappointing, for two reasons. Firstly, C syntax isn't > >> that terrible. > > It's not just the abysmally appalling, hideously horrifying syntax. At > > about everything about C is just *not* "made for human beings" imho. > I've never heard C syntax reviled quite so intensely. What syntax do > you like, out of curiosity? I had a paper some years ago on why C is a horrible language *to teach with* http://www.the-magus.in/Publications/chor.pdf I believe people did not get then (and still dont) that bad for - beginner education (CS101) - intermediate -- compilers, OS, DBMS etc - professional software engineering are all almost completely unrelated -- https://mail.python.org/mailman/listinfo/python-list
Re: min max from tuples in list
On Sunday, December 15, 2013 9:11:15 AM UTC+5:30, Tim Roberts wrote: > Dennis Lee Bieber wrote: > >>Well "performant" is performant enough for the purposes of communicating > >>on the python list I think :D > > Most probably could figure it out as being stylistically similar to > >conformant => something that conforms > >performant => something that performs > Yes, I suspect it comes from people expecting too much consistency. If > something that has "conformance" is "conformant", then something that has > good "performance" must be "performant". And things that have consistency are of course... consistant (not consistent) -- https://mail.python.org/mailman/listinfo/python-list
Re: a question about list as an element in a tuple
On Monday, December 16, 2013 9:27:11 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Dec 16, 2013 at 2:30 PM, liuerfire Wang wrote:
> > TypeError: 'tuple' object does not support item assignment
> > In [5]: a
> > Out[5]: ([1, 1], [])
> > no problem, there is an exception. But a is still changed.
> > is this a bug, or could anyone explain it?
> It's not a bug, but it's a bit confusing. Here's what happens. The
> augmented assignment operator += triggers an in-place addition (where
> possible; for lists, it's possible), so the original list will be
> changed:
> >>> a = [1]
> >>> b = a
> >>> a += [2]
> >>> b
> [1, 2]
> Whereas using separate assignment and addition creates a new list:
> >>> a = a + [3]
> >>> a
> [1, 2, 3]
> >>> b
> [1, 2]
> To handle both mutable types (like list) and immutable ones (like
> str), the augmented assignment operators have to be able to choose
> whether or not they change their object:
> >>> a = "1"
> >>> b = a
> >>> a += "2"
> >>> b
> '1'
> >>> a
> '12'
> So what happens under the hood is, more or less:
> a += [2]
> # ... is equivalent to ...
> a = a.__iadd__([2])
> Which can be explored interactively:
> >>> a = [1]
> >>> a.__iadd__([2])
> [1, 2]
> >>> a
> [1, 2]
> The __iadd__ function ("in-place add") returns the new result, and in
> the case of the list, that's done by changing the list. The assignment
> is then done, which does nothing here, but with strings, is the
> critical part of the job. So far, so good.
> Now, when that result gets assigned to the tuple, we have a problem.
> Tuples are immutable - can't change length (no appending), and can't
> assign to elements. So when the final step happens, an exception is
> thrown. At that point, the tuple is complaining "Hey, you can't assign
> to me!", but the list has already done the appending, and it's too
> late to undo that. So the list has changed, and when you go look at
> it, you see the change (since the list is the same whether you find it
> from the tuple or somewhere else), which creates the confusing
> situation of throwing an exception after doing exactly what you
> wanted.
> Python exceptions aren't like SQL errors, causing a rollback of the
> whole transaction. Or, more generally, Python expressions and
> statements aren't transactional. So it's entirely possible, if a
> little confusing, for part of a job to happen. Let's take another
> example that has side effects:
> tup = (1,2,3)
> tup[2] = input("Enter something: ") # use raw_input() in Python 2
> Tuple assignment can't work... but it's fairly clear that this
> _should_ still show the prompt and wait for the user to type
> something, and only throw the exception later on. It's not as obvious
> in the augmented assignment example, but both are actually doing the
> same thing.
> Hope that helps!
Heh!
Nice question... even nicer explanation!!
I thought I knew that imperative programming is a bad idea:
http://blog.languager.org/2012/11/imperative-programming-lessons-not.html
Never cease to be surprised how bad an idea it is!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Comparing values of counter in python 3.3
On Monday, December 16, 2013 8:10:57 AM UTC+5:30, Roy Smith wrote:
> rusi wrote:
> > On Monday, December 16, 2013 7:29:31 AM UTC+5:30, alex23 wrote:
> > > > # Need to compare values of counter and reject in function/routine in
> > > > value in counter2 is higher then value in counter1 for a current key
> > > [(k,Counter2[k]) for k in Counter2 - Counter1]
> > Why not just?
> > Counter2 - Counter1
> > And if you want to uncounterify it then
> > dict(Counter2 - Counter1)
> > > Counters are awesome.
> > Yes -- agreed. But 'counter' is a strange name -- after checking whether
> > 'bag' and 'multiset' are there in the library, I would not think to
> > check anything else.
> Bag and multiset are names only CS weenies would think to look for.
> Counter is the name for the rest of us :-)
Weenie? WEENIE?!? Harrumph! Im offended!!
More seriously: One issue with all the new good stuff --
comprehensions, generator expressions, dict comprehensions etc is that
the motivations/explanations are all couched imperatively.
So
1.
[something(v) for v in lst]
is understood as
2.
newlst = []
for v in lst:
newlst.append(something(v))
and so the comprehension is just a one-liner for the for-loop
[Witness Mark's comments earlier that the for loop is more readable]
If instead the comprenension is seen as a programmers equivalent of the
set theory expression
3.
{something(v) | v ∈ lst } # if the unicode gods deign to allow!
then they would be more easily appreciated and used.
The extreme example of this is that the implementation of
comprehensions were and continue to be wrong because of variable
leakage because 1 is equivalenced to 2 rather than 3.
To come back to the topic: Counter suggesting DO-ing counting
whereas bag/multiset suggests BE-ing with counts;
ie the one sounds imperative, the other declarative
(which of course may mean its a CS-weenie speaking!)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Comparing values of counter in python 3.3
On Monday, December 16, 2013 7:29:31 AM UTC+5:30, alex23 wrote: > > # Need to compare values of counter and reject in function/routine in value > > in counter2 is higher then value in counter1 for a current key > [(k,Counter2[k]) for k in Counter2 - Counter1] Why not just? Counter2 - Counter1 And if you want to uncounterify it then dict(Counter2 - Counter1) > Counters are awesome. Yes -- agreed. But 'counter' is a strange name -- after checking whether 'bag' and 'multiset' are there in the library, I would not think to check anything else. -- https://mail.python.org/mailman/listinfo/python-list
Re: request for guidance
On Saturday, December 14, 2013 10:41:09 AM UTC+5:30, David Hutto wrote:
> Don't get me wrong, I didn't mean reinventing the wheel is a bad
> thing, just that once you get the hang of things, you need to
> display some creativity in your work to set yourself apart from the
> rest.
> Nowadays, everyone's a programmer.
> If it weren't for reinventing the wheel, then we wouldn't have
> abs(antilock breaking systems), or new materials, or different
> treading for water displacement or hydroplaning.
> The point was just to try something in python, and to 'boldly go
> where no 'man' has gone before'. Just to remind her that it's not
> just about python, but what you can accomplish with it, and
> distinguish yourself from others.
To complement what David is saying, programmers need to know
programming but a lot else besides in order to become even minimally
productive. eg
Primary Development tools/aids
1. Help
2. Interpreter-CLI
3. Interpreter-Introspection
4. Editor
5. Completion ('intellisense')
6. Tags (navigation)
7. Refactoring
8. Integration with 'non-programming' below
Other Development Tools
1. Debugger
2. Profiler
3. Heap Profiler
4. Coverage
Non-Programming
Area | Tool(s)
--+--
packaging| distutils, setuptools
| pip
| Native tools (eg apt)
versioning | hg, git, bzr
multiple pythons | virtualenv
automation | tox
testing | unittest, nose, pytest
build| scons, make...
deployment | fabric
Yeah I know this can sound a bit intimidating :-)
In actual practice most active developers need to know about 30% of the above
But you need to know which is your 30% ;-)
PS. Yeah you can say Im just a teacher trying to justify my job!! On
the other side, for years I argued with the authorities that a 3 year
CS degree could be reduced to 6 months.
But I dont think it could be reduced to 6 days... or even 6 weeks
--
https://mail.python.org/mailman/listinfo/python-list
Re: CP65001 fails (was re: ...)
On Sunday, December 15, 2013 10:30:12 AM UTC+5:30, Steven D'Aprano wrote: > I'm sorry, I was under the impression that Mark had done most of the > work. I hadn't realised that others had contributed most of the practical > advice. To be fair, I added the stuff to the wiki on Mark's prompting. Earlier was under the impression that not anyone could edit the wiki. -- https://mail.python.org/mailman/listinfo/python-list
Re: CP65001 fails (was re: ...)
On Sunday, December 15, 2013 4:21:08 AM UTC+5:30, Steven D'Aprano wrote: > Apart from annoying the bystanders, your repeated angry and abusive > screeds aimed at JMF in particular but others as well over minor > formatting issues is more disruptive than the issues you are complaining > about. I am grateful to you for taking the time and effort to write up a > wiki page on fixing this issues, but gratitude for that will only go so > far in forgiving disruptive behaviour. I guess you are talking about https://wiki.python.org/moin/GoogleGroupsPython As you will see https://wiki.python.org/moin/GoogleGroupsPython?action=info most of the edits there are by rurpy and the recent ones (sorry I missed putting comments) which are for a more automatic solution are by me. [No I am not asking for 'gratitude'... just sayin' and giving some context] There was this ridiculous guy Jonas https://mail.python.org/pipermail/python-list/2013-October/658671.html who responded to calls to correct the typical GG mess with more and more exceptional rudeness https://mail.python.org/pipermail/python-list/2013-October/658816.html So I thought to myself: Well this is too much! And yet while the rudeness is indefensible the technical grumble: "I'm not going to go deleting newlines" is not. Hell! Rather than making a socio-eco-politco-anthropo-marxist-feminist mess, why dont we fix a technical problem technically?? To me all this GG complaining sounds like some elderly mom-pop-uncle who weeps/coaxes/moans/pleads/grumbles/ about a fused light bulb, rather than climbing on a stool and changing the bloody thing. So, given that I am a programmer I came up (with some tips from Kushal Kumaran?) with a technical solution. If I were an ace programmer (can learn JS in a day and make useful contributions) it would have been a 0-click solution. [And if I were a super-ace, it would have been a beneficient virus, that would comb the net, discover all GG users and self-install without anyone's knowing] Since I am not ace or super-ace but only a humble programmer (like Dijkstra!) its a 2-click solution that needs installation :-; Still, GIVEN THE CONTEXT -- addressing not anyone but an already-GG user who is clueless about the nuisance he's causing -- I think this solution is easiest to all. -- https://mail.python.org/mailman/listinfo/python-list
Re: request for guidance
On Saturday, December 14, 2013 10:41:09 AM UTC+5:30, David Hutto wrote: > Don't get me wrong, I didn't mean reinventing the wheel is a bad thing, just > that once you get the hang of things, you need to display some creativity in > your work to set yourself apart from the rest. > Nowadays, everyone's a programmer. > If it weren't for reinventing the wheel, then we wouldn't have abs(antilock > breaking systems), or new materials, or different treading for water > displacement or hydroplaning. > The point was just to try something in python, and to 'boldly go where no > 'man' has gone before'. > Just to remind her that it's not just about python, but what you can > accomplish with it, and distinguish yourself from others. > On Fri, Dec 13, 2013 at 11:56 PM, Chris Angelico wrote: > On Sat, Dec 14, 2013 at 3:48 PM, David Hutto wrote: > > In my opinion, a novice always tries to reinvent the wheel. Take for example > > a simple text editor. > Which isn't a bad thing. Especially in that particular case, it's good > to try your hand at writing a text editor - most of the hard > grunt-work is done for you (just plop down an edit control - in some > toolkits you can even deploy a control with full source code > highlighting), so you can focus on figuring out what it is that makes > yours different. And then you'll appreciate other editors more :) But > along the way, you'll learn so much about what feels right and what > feels wrong. And maybe you can incorporate some of your own special > unique features into whatever editor you end up using... quite a few > are scriptable. For the young-n-enthu "Make haste slowly!" is usually good advice -- https://mail.python.org/mailman/listinfo/python-list
Re: min max from tuples in list
On Friday, December 13, 2013 11:58:51 AM UTC+5:30, Robert Voigtländer wrote: > >I've heard the term used often. It means something like, "performs > >well" or "runs fast". It may or may not be an English word, but that > >doesn't stop people from using it :-) > > If "google" can be used to mean "make huge amouts of money with a > > product that is inherently flawed" then I'll happily accept "performant" > > as an English word, regardless of whether the English variant is UK, US, > > Australian, New Zealand, Soth African, Geordie, Glaswegian or any other :) > Indeed it's not an english word. I have to stop using it. In German > it's used with the meaning of "runs fast". Even though it's already > not that clearly defined there. > Thanks for the help on the topic of data aggregation. It helped a > lot and I again learned somthing. I have a performant .. well > .. fast running solution now. Well "performant" is performant enough for the purposes of communicating on the python list I think :D -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] trying socket as a replacement for nc
On Friday, December 13, 2013 5:50:03 PM UTC+5:30, Jean Dubois wrote: > to make the script check itself whether pyhon2 or python3 should be used? As far as I know both (2 and 3) worked Do you have some reason to suspect one works and other not? -- https://mail.python.org/mailman/listinfo/python-list
Re: [newbie] trying socket as a replacement for nc
On Friday, December 13, 2013 5:50:03 PM UTC+5:30, Jean Dubois wrote: > Op vrijdag 13 december 2013 09:35:18 UTC+1 schreef Mark Lawrence: > > Would you please read and action this > > https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the > > double line spacing that accompanied the above, thanks. > > -- > > Mark Lawrence > Dear Mark, > I'm sorry for the inconvenience my postings may have caused. I now have > followed > the instructions on the link you mentioned and installed the plugin en > python-script. Thanks for cooperating > hope it worked (I saw the text light up yellow when pressing the edit-key a > second time). A small suggestion from a newbie: it would perhaps be possible > to make the script check itself whether pyhon2 or python3 should be used? Yes... Half way The double-spacing problem is cured However the long-lines remain (see your "hope it worked..." above) Did you click the edit button both before and after your typing? The 'before' should remove the double-spaced (old >...) lines The 'after' should even out the right margins of what you've just typed > thanks for having patience with me Yes and you too please bear with us as we iron out this little irritant niggle -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Friday, December 13, 2013 10:13:11 PM UTC+5:30, Chris Angelico wrote: > On Sat, Dec 14, 2013 at 3:39 AM, Mark Lawrence wrote: > > You'll have to wait until the cows come home on two counts. One, he's never > > yet provided any evidence to support any statement that he's ever made here. > > Second, he's still not smart enough to stop sending double spaced google > > crap. > I don't know that it's a matter of not being smart enough. It's just > as likely to be a deliberate choice, as that method of posting ensures > that the quality of the style matches the quality of the substance. Correlates? Ok Ensures?? Citation needed -- https://mail.python.org/mailman/listinfo/python-list
Re: request for guidance
On Friday, December 13, 2013 10:45:22 AM UTC+5:30, jennifer stone wrote: > greetings > I am a novice who is really interested in contributing to Python > projects. How and where do I begin? Good to see new names! How much python do you know/studied/coded? -- https://mail.python.org/mailman/listinfo/python-list
Re: Optimizing list processing
On Friday, December 13, 2013 8:31:37 AM UTC+5:30, Steven D'Aprano wrote:
> I don't know of any reasonable way to tell at runtime which of the two
> algorithms I ought to take. Hard-coding an arbitrary value
> ("if len(table) > 500") is not the worst idea I've ever had, but I'm
> hoping for something more deterministic which can be cheaply calculated
> at runtime.
Have you seen guppy and heapy?
http://guppy-pe.sourceforge.net/
Even if you dont use it directly, it should have syscalls that you can steal
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need help with file object
On Friday, December 13, 2013 9:59:25 AM UTC+5:30, Unix SA wrote:
> s=open('/tmp/file2')
>s.write(line)
Among other things you are missing a write mode
(2nd optional argument to open)
http://docs.python.org/2/tutorial/inputoutput.html#reading-and-writing-files
--
https://mail.python.org/mailman/listinfo/python-list
Re: Trouble with Multi-threading
On Thursday, December 12, 2013 7:30:38 AM UTC+5:30, Roy Smith wrote: > In article Steven D'Aprano wrote: > > When did this forum become so intolerant of even the tiniest, most minor > > breaches of old-school tech etiquette? Have we really got nothing better > > to do than to go on the war path over such trivial issues? Out of five > > responses to the Original Poster's email, there was *one* helpful reply, > > followed by no fewer than four people playing "Stacks on the n00b" making > > the same comment about being unable to delete the message. I'm sure all > > four of you think you are ever such wits, but you're only half right. > I believe I started off the chain of responses you're referring to. I > meant it semi-humorously, but also with a point. It is clear it turned > out to be harmful, and for that I apologize. Sniping at someone -- especially a newcomer -- for a piece of technical irrelevantia is unfortunate. However your semi-humorous pointing out was good because it shows that all posting methods have their hiccups: html mail undesired and nonsensical footers reply/reply-all mixups repeated posts long and double-spaced lines others Ive missed Reminds me that sometime ago when GG was habitually double-posting, Steven started quadruple-posting, giving some of us a rare leg-pulling opportunity :D > I share your dismay at where this group is going, and feel bad that I > inadvertently moved it further in that direction. Unnecessary and uncalled for irascibility is of course a degradation. But (from my pov) a bunch of people -- especially so-called techies -- unable to distinguish the following 3 is a much bigger degradation. 1 Problems caused by conscious malefic intent 2 Kids/noobs/ignoramuses/immature just being themselves 3 Problems of communication technology Conflating 1,3 with 2 will drive many of them (2s) away which is a significant loss for the community -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Thursday, December 12, 2013 7:12:32 AM UTC+5:30, Roy Smith wrote:
> rusi wrote:
> > Kernighan and Ritchie set an important "first" in our field by making
> > "Hello World" their first program.
> Yup.
> > People tend to under-estimate the importance of this:
> > Many assumptions need to be verified/truthified/dovetailed
> > starting from switching on the machine onwards for this to work.
> At the time that they wrote it, very few people who used computers ever
> got anywhere near the power switch :-) But, the point is valid. To get
> "Hello, world" to print, you've got to figure out a lot of stuff.
> Predating the whole agile movement by two decades, it is the
> quintessential MVP. It compiles and runs. The rest is just adding
> features and fixing bugs.
Which comes back full-circle to where we started: if
main() { printf("Hello World\n"); }
is the foundation on which other programs are built, then later excising
the print(f) is a significant headache -- at least for teachers as Steven
also seems to have found.
If instead the print was presented more as a 'debug' -- when something
goes wrong stick a probe in there and figure the problem -- then
leaving it there would be as unacceptable as a car mechanic giving you
your keys with the hood open and parts lying around.
Anecdote about the great mathematician Gauss: He was asked why
his writings were so devoid of motivations/explanations. He answered:
Do you leave the scaffolding after the building is built?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Disable HTML in forum messages (was: Movie (MPAA) ratings and Python?)
On Thursday, December 12, 2013 6:42:42 AM UTC+5:30, Ben Finney wrote: > Dan Stromberg writes: > > I found a "remove formatting" button in gmail's composer, and used it > > on this message. Does this message look like plain text? > Still sent with an HTML part, so some other change must be needed to > disable that. > > There isn't a lot of e-mail programs that don't do HTML anymore. > Many of the better mail clients allow the user to explicitly stop > rendering HTML (but still have it available, as Steven points out). > Disabling HTML in messages is a good idea: HTML rarely adds anything > useful to a message in a discussion forum, but it can cause the mail > program to do actions unwanted by the user (e.g. fetch images from > elsewhere, or run ECMAScript, or invoke HTML rendering bugs). When you click on send/reply in gmail, there's a small down-triangle next to the dustbin, inside which you will find a plain text option The problem is that then your other mails (may) become plain text and your friends/recipients will wonder whether you've entered a time-machine and gone back to 1990!! Many people find it simpler to just use Google groups. It also has its problems (as do all methods!) but in sum its the easiest option to use. -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Wednesday, December 11, 2013 9:31:42 PM UTC+5:30, bob gailer wrote:
> On 12/11/2013 3:43 AM, Chris Angelico wrote:
> > When you tell a story, it's important to engage the reader from the
> > start...explain "This is how to print Hello World to the
> > console" and worry about what exactly the console is (and how
> > redirection affects it)
> Highly agree. I was once given FORTRAN course materials and an
> assignment to teach this course. The first morning was spent on how to
> construct expressions! No context as to what a program was or what it
> might do or how to run it.
> As soon as that class was over I rewrote the materials so the first
> morning was how to write and run(batch job submission) a program that
> read a record, did a simple calculation and wrote the results.
Kernighan and Ritchie set an important "first" in our field by making
"Hello World" their first program.
People tend to under-estimate the importance of this:
Many assumptions need to be verified/truthified/dovetailed
starting from switching on the machine onwards for this to work.
And its quite a pleasurable sense of achievement when it finally holds
together -- something which is sorely missing in the Dijkstra approach.
However when we have an REPL language like python, one has the choice
of teaching the hello-world program as:
print ("Hello World")
or just
"Hello World"
The second needs one more assumption than the first, viz that we are in the
REPL, however on the whole it creates better habits in the kids.
[BTW: From the theoretical POV, imperative programming is 'unclean' because
of assignment statements. From the practical POV of a teacher, the
imperativeness of print is a bigger nuisance in students' thinking patterns
]
> I certainly felt better about teaching this way.
> Asides:
> One student (PhD in Physics) looked at X = X + 1 and said "no it doesn't".
Yes thats one issue in most modern imperative languages that the older
generation
(Pascal-family) did not have, viz that assignment looks like equality.
> Another wrote his first program. I took one look at it and saw the
> mistakes. I explained how to walk thru the program step by step. He
> exclaimed "In that much detail?".
--
https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Wednesday, December 11, 2013 8:54:30 PM UTC+5:30, Chris Angelico wrote: > On Thu, Dec 12, 2013 at 1:44 AM, rusi wrote: > > It is this need to balance that makes functional programming attractive: > > - implemented like any other programming language > > - but also mathematically rigorous > Attractive *to the mathematician*. A more imperative style makes sense > to someone who's grown up with... well, parents... > clean_room() > eat_dinner() > One won't start till the other finishes. Yes its always like that: When you have to figure 2 (or 10) line programs its a no-brainer that the imperative style just works. When the ten becomes ten-thousand, written by a nut who's left you with code whose semantics is dependent on weird dependencies and combinatorial paths through the code you start wishing that - your only dependencies were data dependencies - "Explicit is better than implicit" dinned into the nut's head which BTW are the basic tenets of FP. We have functions in C, in Scheme and in Haskell. The difference is that - in C its impractical and unrealistic to have all functions as (mathematical) functions of the arguments - in Scheme its natural but not enforced - in Haskell its enforced The nice thing about python is that one can (kindof) teach it in the Scheme-like way before showing the C-like side. -- https://mail.python.org/mailman/listinfo/python-list
Re: grab dict keys/values without iterating ?!
On Wednesday, December 11, 2013 8:16:12 PM UTC+5:30, Roy Smith wrote:
> rusi wrote:
> > The classic data structure for this is the trie:
> > General idea: http://en.wikipedia.org/wiki/Trie
> > In python:
> > http://stackoverflow.com/questions/11015320/how-to-create-a-trie-in-python/
> I agree that a trie fits the problem description well. If I were coding
> this up in C or C++, that's probably the data structure I'd use, with
> each node containing an array of pointers to nodes, and the array
> indexed by the ascii value of the next character (this doesn't translate
> well to unicode). Lookup speed would be awesomely fast.
> The problem is, that doesn't make a whole lot of sense in Python. The
> cited implementation uses dicts at each level. By the time you've done
> that, you might as well just throw all the data into one big dict and
> use the full search string as the key. It would be a lot less code, and
> probably run faster.
> Still, as an exercise in learning about a useful (and under-appreciated)
> data structure, implementing this as a trie sounds like a wonderful idea.
I was going to say that Steven's
data = {}
for c in "ABCDEFGHIJKLMNOPQRSTUVWXYZ":
data[c] = {}
is really the first step of the trie approach
except that instead of
key = "Aardvark"
data[key[0]][key] = "some value"
he would need
data[key[0]][key[1:] = "some value"
The catch is keys of length 1 eg "A"
Which makes the fully general (recursively unfolded) version easier
to write, though with all those zillions of dicts probably not very efficient.
Finitizing the trie into fixed small prefixes with leaves containing standard
dicts looks sensible (to me without and testing of either efficiency or
readability!)
The short prefix problem however remains
Of course there are other tricks possible:
If we know that the data is case-insensitive alphabetic ASCII* we can just
normalize the data with
def norm(s): return [ord(c.upper()) -ord('A') for c in s]
then
>>> norm("aBcD")
[0, 1, 2, 3]
and instead of dicts we can use 26-length lists
* O me O my! Ive used the terrible A-word!
Now RUN before the trolls get us!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Wednesday, December 11, 2013 5:16:50 PM UTC+5:30, Oscar Benjamin wrote: > The Electrical Engineering students will subsequently do low-level > programming with registers etc. but at the earliest stage we just want > them to think about how algorithms and programs work before going into > all the hardware specific details. > While reading around this subject I found this interesting (although > verbose) speech from Dijkstra advocating the opposite point of view: > http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html > This definitely wouldn't work for my students but a friend of mine > studied CS (at Warwick?) and his course worked as Dijkstra describes. > In the first year they don't touch a real programming language or > write any actual programs. They take exams in pseudocode and formal > proofs of correctness. Then after a year of studying algorithms, > linguistics, semantics, proof, mathematics and so on they write their > first hello world program in a real programming language. I don't > really know whether he's any good at programming but he's certainly a > good mathematician. A government form -- say for filing income tax -- and poetry may both be in English but one doesn't read them with the same attitude! Dijkstra talks in so much hyperbole that one does not take him literally. In particular if you want to take him seriously, you must not take him literally. [I remember reading somewhere that in CS arrogance is measured in nano-dijkstras] I believe there is a truth in the line that Chris and Gene take of getting students' hands dirty early. Equally there is truth in Dijkstra's line that students need the habit of thinking and reflecting before diving in. Now if you believe that one is clearly more important than the other, your way is clear. However what if you want to balance both? Its a challenge... It is this need to balance that makes functional programming attractive: - implemented like any other programming language - but also mathematically rigorous No python is not strictly a functional language but it can be bent to seem that way more than C/C++/Java/what-have-you -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there any advantage to using a main() in python scripts?
On Wednesday, December 11, 2013 7:47:34 PM UTC+5:30, Roy Smith wrote: > JL wrote: > > Python scripts can run without a main(). What is the advantage to using a > > main()? Is it necessary to use a main() when the script uses command line > > arguments? (See script below) > > #!/usr/bin/python > > import sys > > def main(): > > # print command line arguments > > for arg in sys.argv[1:]: > > print arg > > if __name__ == "__main__": > > main() > No, it's not necessary, but it's a good idea. > For one thing, it lets you import your script without actually running > it. We recently tracked down a long-standing bug where some maintenance > script we had started out with: > import os > os.environ['DJANGO_SETTINGS_MODULE'] = 'whatever' > somebody imported that script in another part of the system because > there was some convenient definition that he wanted to reuse. > Unfortunately, the act of importing the script changed the environment! > The fix was to move the setting of the environment variable to inside > the main() routine. If you always follow the rule that you always put > all your executable code inside main(), you'll never run into problems > like that. I guess these are important but somewhat advanced considerations. For a beginner, its important to get that there is a bit of a pun here: The function habitually called 'main' may be called that or anything else It can have or not have an argument as Ben pointed out -- maybe more than one also. The module name __main__ is however sacrosanct and hardwired into python. The habit of connecting the one with the other is partly conventional and partly unavoidable -- https://mail.python.org/mailman/listinfo/python-list
Re: grab dict keys/values without iterating ?!
Reordering to un-top-post. > On 11.12.2013 06:47, Dave Angel wrote: > > On Wed, 11 Dec 2013 02:02:20 +0200, Tamer Higazi wrote: > >> Is there a way to get dict by search terms without iterating the > > entire > >> dictionary ?! > >> I want to grab the dict's key and values started with 'Ar'... > > Your wording is so ambiguous that each respondent has guessed > > differently. > > I'm guessing that you want all key/value pairs for which the key > > begins with the two letters 'Ar' I'm guessing further that your > > objection to iterating the entire dictionary is not code size but > > performance. > > If both assumptions are valid then I'll point out that a dict has no > > ordering to it. If you want an approach that doesn't iterate over the > > entire structure you'll need to store the data differently. For > > example if you stored all the keys in a sorted list you could use bisect. On Wednesday, December 11, 2013 3:37:08 PM UTC+5:30, Tamer Higazi wrote: > Hi Dave! > You were absolutely right. > I don't want to iterate the entire dict to get me the key/values > Let us say this dict would have 20.000 entries, but I want only those > with "Aa" to be grabed. > Those starting with these 2 letters would be only 5 or 6 then it would > take a lot of time. > In which way would you prefer to store the data, and which functions or > methods would you use effectively to accomplish this task ? The classic data structure for this is the trie: General idea: http://en.wikipedia.org/wiki/Trie In python: http://stackoverflow.com/questions/11015320/how-to-create-a-trie-in-python/ > I deeply apologize of not defining the question more defined. English is > not my mother tongue. > I'll do my best next time. English no issue. But better not to top-post http://en.wikipedia.org/wiki/Posting_style#Top-posting -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem when applying Patch from issue1424152 to get https over authenticating proxies working with urllib2 in Python 2.5
On Tuesday, December 10, 2013 9:52:47 PM UTC+5:30, Mark Lawrence wrote: > On 10/12/2013 15:48, rurpy wrote: > > On 12/10/2013 06:47 AM, Chris Angelico wrote: > >> On Wed, Dec 11, 2013 at 12:35 AM, harish.barvekar wrote: > >> Also: You appear to be using Google Groups, which is the Mos Eisley of > >> the newsgroup posting universe. You'll do far better to instead use > >> some other means of posting, such as the mailing list: > > Using Google Groups is also fine. I and many other posters here > > use it. Chris and some others here dislike Google Groups and want > > everyone to not use it, but that is their personal opinion. > > If Google Groups is most convenient for you please feel free to > > continue using it. You might want to take a look at this page > > which describes how to reduce some of things that annoy people > > like Chris: > >https://wiki.python.org/moin/GoogleGroupsPython > There is no "you might want to" about it. There are two options here, > either read and action the page so we don't see double spaced crap > amongst other things, use another tool, or don't post. There are 10 kinds of people in the world: those who understand binary and those who dont. -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Tuesday, December 10, 2013 4:12:53 PM UTC+5:30, Oscar Benjamin wrote: > On 9 December 2013 19:57, Terry Reedy wrote: > > On 12/9/2013 7:23 AM, Oscar Benjamin wrote: > >> Hi all, > >> I work in a University Engineering faculty teaching, among other > >> things, programming. In our last meeting about improving our teaching > >> syllabus and delivery we've identified the first year programming > >> courses as an area where there is room for improvement and we're > >> considering (mainly on my suggestion) switching to using Python as the > >> first programming language that we use to introduce our students to > >> programming. I'm interested to know if anyone can share experience of > >> a similar situation or can point to any case studies about this. > > A few years ago, MIT switched from Scheme (which I believe originated at > > MIT) to Python for its first course. There might faculty blogs discussing > > the reasons. > Thanks Terry. The best I've found is this: > http://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/ There's this http://danweinreb.org/blog/why-did-mit-switch-from-scheme-to-python which seems to have died -- the internet archive has it here https://web.archive.org/web/20120429151818/http://danweinreb.org/blog/why-did-mit-switch-from-scheme-to-python Neither really talks of why python was chosen In that direction you may want to see why Java has been ousted from CMU: http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/ -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 3:07:36 PM UTC+5:30, Mark Lawrence wrote: > On 10/12/2013 05:16, rusi wrote: > > On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: > >> By the way, I'm curious. Why are discussions about object oriented coding > >> off-topic to Python? This is not a rhetorical question. > > Well OOP on the python list is certainly on topic. > > Interminable discussions about why redrawing the inheritance arrows > > the other way round will save the world is OT (for me!) > One of the great joys of reading this list is how wonderfully OT it can > get. I have the right to make this statement as I started *THIS* > thread. Now what *WERE* we talking about? :) My boy, I see that you are making progress towards your guru -- Nikos. "You are spamming MY THREAD" -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 10:40:27 AM UTC+5:30, Steven D'Aprano wrote: > By the way, I'm curious. Why are discussions about object oriented coding > off-topic to Python? This is not a rhetorical question. Well OOP on the python list is certainly on topic. Interminable discussions about why redrawing the inheritance arrows the other way round will save the world is OT (for me!) -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Tuesday, December 10, 2013 8:49:46 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 09 Dec 2013 05:59:29 -0500, Ned Batchelder wrote: > [...] > > And the cycle continues: > [...] > > Maybe we could just not? Thanks Ned for your attempts at bringing some order and sense in these parts of the universe > A reasonable request, but just because it's reasonable doesn't mean it is > a no-brainer that we shouldn't engage with Mark. Some basic statistics Suppose a random variable X takes 2 values x and y with probabilities p and q=1-p. Then expected value of X E[X] = px + qy p = probability of some good result from an interaction q = 1-p = No good x = benefit value y = harm value > Even if Mark is a crank and beyond the reach of logic, reason or facts, > and I'm 90% convinced his is, consider that he's not the only one reading > this thread. So you are pegging 'no-good-probability' at 90% and so p at 10%. Ok lets accept these. And in the benefit value you include the possible benefit to Mark, to whoever engages with him and the random [no relation of random variable X] lurking reader. So far so good And in the harm-value y, are you including the harm done to the random reader from a disorderly, abusive, fruitless and almost completely OT conversation? > If just one person learns something useful or new from a > reply to Mark, I believe that it is worthwhile. And if 3 people drop out because the levels of bullshit have crossed their thresholds? [BTW: My statistics was never very strong and is now quite rusty. So... Whos that guy who recently added a stats module to python?? Cant remember his name... Maybe I should take some tuitions from him...] -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Monday, December 9, 2013 5:53:41 PM UTC+5:30, Oscar Benjamin wrote: > 5) Learning to program "should be painful" and we should expect the > students to complain about it (someone actually said that!) but the > pain makes them better programmers in the end. Yeah this will get some people's back up -- Atrocious! Preposterous! etc Change the word 'pain' to 'taxing' 'hard' 'challenge' etc and there is much truth in it. Here is Joel Spolsky on why Java is a poor language for this reason: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta Fight About Posting (was: python programming help)
On Monday, December 9, 2013 9:55:19 PM UTC+5:30, rusi wrote: > On Monday, December 9, 2013 9:14:08 PM UTC+5:30, Travis Griggs wrote: > > As long as we’re in full scale rant drift, I’d like to remind others > > of the time honored tradition of changing the post subject, when, > > er, uh, the subject changes. Because this obviously is not > > "programming help" anymore. > I believe you are missing what's actually at issue here. > Lets just look at this thread: > New poster asks help for a homework problem without saying so > Different list members express concern/annoyance with this > [NO technological (3 different technologies) issues here yet] > This -- annoyance+answers -- continues for while until it morphs into > GG-annoyance > The *context* of the earlier annoyance -- kid asking for homework help > without clearly saying so -- is lost in the GG annoyance. > Now GG is clearly annoying > As are kids who ask for homework help without saying so > ¿¿Whats the connection?? I should have mentioned/asked: Are you using Google Groups to post? Your post suffers from one of GG's annoyances – long lines. If you are using it then I wonder about the *content* of your complaint If you are not – and the *form* of your post still has a classic-GG nuisance – then it weakens the anti-GG case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Meta Fight About Posting (was: python programming help)
On Monday, December 9, 2013 9:14:08 PM UTC+5:30, Travis Griggs wrote: > As long as we’re in full scale rant drift, I’d like to remind others > of the time honored tradition of changing the post subject, when, > er, uh, the subject changes. Because this obviously is not > "programming help" anymore. I believe you are missing what's actually at issue here. Lets just look at this thread: New poster asks help for a homework problem without saying so Different list members express concern/annoyance with this [NO technological (3 different technologies) issues here yet] This -- annoyance+answers -- continues for while until it morphs into GG-annoyance The *context* of the earlier annoyance -- kid asking for homework help without clearly saying so -- is lost in the GG annoyance. Now GG is clearly annoying As are kids who ask for homework help without saying so ¿¿Whats the connection?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Experiences/guidance on teaching Python as a first programming language
On Monday, December 9, 2013 5:53:41 PM UTC+5:30, Oscar Benjamin wrote: > Hi all, > I work in a University Engineering faculty teaching, among other > things, programming. In our last meeting about improving our teaching > syllabus and delivery we've identified the first year programming > courses as an area where there is room for improvement and we're > considering (mainly on my suggestion) switching to using Python as the > first programming language that we use to introduce our students to > programming. I'm interested to know if anyone can share experience of > a similar situation or can point to any case studies about this. 1 Some Background = Early in my teaching career - 1988 -- I experienced what it means to switch from Pascal to Scheme to teach programming. And in 2002 I swtiched to using python. I may talk a bit about this but before that… 2 Some Philosophical Context Some years ago I read in a book (I think it was called "Heart of Philosophy") about the difference between 'ideas' and 'concepts.' Ideas are large vague touchy-feely things like freedom, love, justice etc; things that matter but poets deal with better than intellectuals. Concepts are the basic currency for an academic. In a typical 1-hour class you deal with a few and in a lifetime you deal with thousands; in short they are a dime a dozen -- especially if you are an academic. And yet if you have a conscience you'd know that covering the concepts specified in a formal printed syllabus is cheating. What really needs to be conveyed are a few ideas: - modular code - code invariants - abstractions - Syntax, semantics and the large grey in between which for want of a better word we may call 'structure' - Recursion much wider than people think see http://blog.languager.org/2012/05/recursion-pervasive-in-cs.html - Interpretation see http://blog.languager.org/2013/08/applying-si-on-sicp.html - Computable and non-computable - The meaning and significance of the word 'code' - (Even more vaguely) beautiful (and ugly) code Before reading on, I suggest you think what for a while what for you are important/core ideas and then what vehicles/mediums are conducive/obstructive to them. 3 My Prejudices === Historically I've been associated with functional programming. While I am not so passionate about it as when I was half my age. still I'd say: - FP *as a philosophy* collects a bunch of stuff -- technology, practices, culture -- that conduces to good programming even for kids who after the course never use FP *as a technology* See http://blog.languager.org/2012/10/functional-programming-lost-booty.html - By contrast OOP is mostly (at best) clerical common sense -- organizing libraries to be easily searchable is better by data than by code. At worst OOP is hogwash -- inheritance. And so… - Python which can be quite functional, imperative and object oriented has a rather special place. Because it is object oriented you will be able to use it to silence those who are subscribed to that religion. Because it is imperative you can write straightforward code -- 'scripts' -- without undue fanfare Because it is functional (well almost -- I have some beefs in this regard) you can use it as a vehicle to actually convey important *ideas* in short space and time - For me Lisp (closely followed by APL) are the ultimate in programming paradigms. However they are not serious technology in 2013. [Even the birthplace of Scheme -- MIT -- has switched to python]. And so in 2013 python occupies a sweet spot in the sense of being academically clean and realistically usable. - That said there are some important elements of FPLs, most notably a polymorphic type discipline, that are sorely missing from python. Unfortunately Haskell is much harder to teach/learn than python and with each new addition only gets harder. So python remains even with its lacks, an academically sound language. 4 CS-Edu Writings = My CS-101 syllabus from the early 90s -- uses gofer a predecessor of a predecessor of Haskell http://www.the-magus.in/Publications/ip.pdf Some more general CS-Edu related writings, containing strewn about "FP is a good idea" http://blog.languager.org/2011/02/cs-education-is-fat-and-weak-1.html and following 2 posts -- रुसि मोदि ["Rusi Mody" in devanagari so that GG will not use an obsolete charset] -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Monday, December 9, 2013 10:56:28 AM UTC+5:30, ru...@yahoo.com wrote: > On 12/08/2013 09:46 PM, rusi wrote: > > On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: > >> On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: > >[...] > >> Does GG not give you some way of inspecting the post's full headers? > > Well I spent half hour looking around -- both inside GG and of course > > searching before asking. > If you click on the little "down" triangle to the right > of the "reply" button for a message, you'll get a menu > that includes "Show Original". You can see the headers > including the "Content-Type:" in that original. Thanks rurpy -- I only looked for how one may set and not just what is. So now I look at my own post in GG and see Content-Type: text/plain; charset=UTF-8 So far so good. However when I point firefox at my own post in the archive https://mail.python.org/pipermail/python-list/2013-December/662015.html firefox shows encoding as Windows-1252. Note Ive looked at a dozen random pages and for all FF shows encoding as utf-8 except the python list archive ones which show as Win 1252 Note looking into the html I see How us-ascii becomes Win-1252 is outside the reach of my meagre intelligence! Though I still suspect something is not quite right with the python mailing-list and/or archive in respect of char encodings. [Am I beginning to sound like jmf is my guru :-) ] -- https://mail.python.org/mailman/listinfo/python-list
Re: python programming help
On Monday, December 9, 2013 10:37:38 AM UTC+5:30, ru...@yahoo.com wrote: > On 12/08/2013 05:27 PM, Mark Lawrence wrote: > > On 09/12/2013 00:08, wrote: > >> On 12/08/2013 12:17 PM, Chris Angelico wrote: > >>> On Mon, Dec 9, 2013 at 6:06 AM, rafaell wrote: > >[...] > > To the OP, please ignore the above, it's sheer, unadulterated rubbish. > > Nobody has ever been bullied into doing anything. People have however > > been asked repeatedly to either A) use the link referenced above to > > avoid sending double spaced crap here from the inferior google groups > > product or B) use an alternative technology that doesn't send double > > spaced crap. > Mark, I appreciate your calm and reasonable requests for people > to checkout the page you gave a link to, that's why I repeated > your advice. It is also why I responded to Chris and not to you. Yes agreed. > However it does not change the fact that people here have responded > in rather extreme way to GG posts including calling GG users "twits" > and claiming GG posts damage their eyesight, as well as repeatedly > denying the obvious fact that GG is much easier to use for many than > to subscribe to a usenet provider or to a mailing list. One frequently > sees words like "crap", "slimy", "rubbish" etc to describe GG posts > which is pretty intimating to people who just want some help with a > python question using a tool they already know how to use and have > had no complaints about in other places. About the last -- no complaints about (that) in other places -- Ive recently seen that on the html/stylesheets/javascript lists (not sure which) there are also annoyed complaints about GG. About the rest -- when people get annoyed they say and do things they would not otherwise do. The sensible not-yet-annoyed-enough-to-lose-the-head folks should try to cure the annoyance rather than get annoyed with it -- dont you think? In short if we are programmers we should be thinking bug-fixes when we are bugged :-) And what is put up here https://wiki.python.org/moin/GoogleGroupsPython (only yesterday BTW) is a dynamically loadable GG-bugfix. -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
Thanks for the info. On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote: > On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote: > > PS Can some kind soul inform me whether I could convince GG to unicode > > my post? > Does GG not give you some way of inspecting the post's full headers? Well I spent half hour looking around -- both inside GG and of course searching before asking. > Anyway, here you go: > Content-Type: text/plain; charset=UTF-8 > Your plan succeeded. > Personally, I wouldn't stress too much about this. While it would be > nice, and desirable, for GG to always use UTF-8 instead of picking a > different encoding based on the phase of the moon, the main thing is that > it picks a valid encoding. So far I see no reason to accuse GG of using > an invalid encoding. Valid but legacy encodings are better than > mojibake :-) Heh! I'm hardly a heavy-duty user of unicode -- just keeping track of bugs and workarounds. I am of course using 'bug' in a wide pragmatic sense of preventing communication. Mojibake is a technical problem. Non (human) communication is a more fundamental problem. Keeping an eye on the latter is (for me) a bigger issue than the former. -- https://mail.python.org/mailman/listinfo/python-list
Re: ASCII and Unicode
On Monday, December 9, 2013 1:41:41 AM UTC+5:30, giacomo boffi wrote: > the wrong one... i.e, the one JUST BEFORE your change of > subject --- if i look at the "ellipsis" post, i see the same encoding > that you have mentioned > sorry for the confusion And thank you for pointing the way to the culprit, viz. GG trying to be too clever. [Since you neglected to close your I am included in it :-) ] -- https://mail.python.org/mailman/listinfo/python-list
Re: interactive help on the base object
On Monday, December 9, 2013 8:11:47 AM UTC+5:30, zipher wrote: > >> What methods, if any does it provide? Are they all abstract? etc??? > > Pretty much nothing useful :-) > > py> dir(object) > > [...] > So (prodding the student), Why does everything inherit from Object if > it provides no functionality? Thats right. What does a collection object like [] or the empty set ∅ (assuming the unicode-gods will allow and bless that) do when it collects nothing? Lets make sure all lists and sets start non-empty. And why have a stupid number like 0 when it counts nothing? Lets go back to roman numerals which is so much more… > Practicality-beats-purity-yours? Practical!!⸮¿¡ PS Can some kind soul inform me whether I could convince GG to unicode my post? -- https://mail.python.org/mailman/listinfo/python-list
Re: ASCII and Unicode
On Sunday, December 8, 2013 10:52:34 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 07 Dec 2013 17:05:34 +0100, giacomo boffi wrote: > > Steven D'Aprano writes: > >> Ironically, your post was not Unicode. [...] Your post was sent using > >> a legacy encoding, Windows-1252, also known as CP-1252 > > i access rusi's post using a NNTP server, and in his post i see > > Content-Type: text/plain; charset=UTF-8 > But *which post* are you looking at? > I have just looked at three posts from him: > Rusi's original post, where he used the ellipsis characters: > Subject: Re: Managing Google Groups headaches > Date: Thu, 5 Dec 2013 23:13:54 -0800 (PST) > Content-Type: text/plain; charset=windows-1252 > Then his reply to me: > Subject: Re: ASCII and Unicode [was Re: Managing Google Groups headaches] > Date: Fri, 6 Dec 2013 18:33:39 -0800 (PST) > Content-Type: text/plain; charset=UTF-8 > And finally, his reply to you: > Subject: Re: ASCII and Unicode > Date: Sun, 8 Dec 2013 08:41:10 -0800 (PST) > Content-Type: text/plain; charset=ISO-8859-1 > It seems to me that whatever client he is using to post (I believe it is > Google Groups web interface?) varies the encoding depending on what > characters are included in his post. > > is it possible that what you see is an artifact of the gateway? > I doubt it. Unfortunately the email mailing list archive doesn't display > all the email headers, but for the record here is his original post as > seen by the email mailing list: > https://mail.python.org/pipermail/python-list/2013-December/661782.html > If you view source, you'll see that Mailman (the mailing list software) > sets the webpage encoding to US-ASCII and encodes the ellipses to …, > which is a perfectly reasonable thing for a web page to do. So we can be > confident that when Mailman saw Rusi's post, it was able to correctly > decode the message and see ellipses. > Although I think that (probably) Google Groups is being stupid by varying > the charset (why not just use UTF-8 always?), at least it is setting the > charset correctly. I think GG is being being sweet and affectionate and delectable enough that a 💩 in the footer will keep it stuck at UTF-8 you think ?? :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: ASCII and Unicode
On Saturday, December 7, 2013 9:35:34 PM UTC+5:30, giacomo boffi wrote: > Steven D'Aprano writes: > > Ironically, your post was not Unicode. [...] Your post was sent > > using a legacy encoding, Windows-1252, also known as CP-1252 > i access rusi's post using a NNTP server, > and in his post i see > Content-Type: text/plain; charset=UTF-8 > is it possible that what you see is an artifact > of the gateway? Thanks for checking that! -- https://mail.python.org/mailman/listinfo/python-list
Re: Origin of eval()-ing in separate namespace object
On Sunday, December 8, 2013 8:09:39 PM UTC+5:30, Jussi Piitulainen wrote: > rusi writes: > > On Sunday, December 8, 2013 4:05:54 PM UTC+5:30, Kalinni Gorzkis wrote: > > > By which languages(s) Python was inspired to support evaluating > > > expressions and executing statements in a separate "namespace" > > > object? > > > This syntax: > > > eval(expression,globals) or exec(code,globals) > > > What is the origin of the functionality provided by the globals > > > argument? > > Been here since the days of scheme at least > > http://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29 > > For the record lisp was conceptualized in the late 50s and > > implemented by 1960. By the 80s it was widely regarded as the > > premier AI language but it was also clear to users that the scoping > > rules were terribly wrong. So a number of the then lisps coalesced > > and re-separated into 2 major dialects -- scheme and common lisp. > > I expect it -- 2 argument eval -- goes all the way back to the > > earliest lisp but Ive not access to the history. > Yes. From p. 13 of LISP 1.5 Programmer's Manual (the preface is dated > in 1962): > # _evalquote_ is defined by using two main functions, called _eval_ > # and _apply_. _apply_ handles a function and its arguments, while > # _eval_ handles forms. Each of these functions also has another > # argument that is used as an association list for storing the values > # of bound variables and function names. Heh – I am nostalgia-fied! Wrote a Lisp interpreter as a student degree project in 1986. Tried to use the Lisp 1.5 manual then but it was too archaic for me to understand. So mostly chewed on the UCI Lisp manual. Took me some years to understand that dynamic scoping was not my mistake but Lisp's!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Centring text in a rect in PyGame?
On Sunday, December 8, 2013 7:36:04 PM UTC+5:30, Tim Golden wrote: > On 07/12/2013 12:41, Eamonn Rea wrote: > > First of all. Id like to say I have no idea how these mailing lists > > work, so I dont know if this'll come through right, but we'll see I > > guess :-) I'm coming from the Google Group comp.lang.python, and was > > suggested to use this instead. Assuming attachments and images work, you > > should have an image of my code�s result and the attached code files. Hi Eamonn There are some new instructions/suggestions to make google groups easier on you (and other readers!) https://wiki.python.org/moin/GoogleGroupsPython If you try them and they work (or even if they dont!) please let me know. Particularly note the new section at the end https://wiki.python.org/moin/GoogleGroupsPython#Automatic_correction_.28EXPERIMENTAL.29 -- https://mail.python.org/mailman/listinfo/python-list
Re: Origin of eval()-ing in separate namespace object
On Sunday, December 8, 2013 4:05:54 PM UTC+5:30, Kalinni Gorzkis wrote: > By which languages(s) Python was inspired to support evaluating expressions > and executing statements in a separate “namespace” object? > This syntax: > eval(expression,globals) or exec(code,globals) > What is the origin of the functionality provided by the globals argument? Been here since the days of scheme at least http://docs.racket-lang.org/guide/eval.html#%28part._namespaces%29 For the record lisp was conceptualized in the late 50s and implemented by 1960. By the 80s it was widely regarded as the premier AI language but it was also clear to users that the scoping rules were terribly wrong. So a number of the then lisps coalesced and re-separated into 2 major dialects -- scheme and common lisp. I expect it -- 2 argument eval -- goes all the way back to the earliest lisp but Ive not access to the history. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is It Bug?
On Sunday, December 8, 2013 6:28:24 AM UTC+5:30, Mahan Marwat wrote:
> Why this is not working.
> >>> 'Hello, World'.replace('\\', '\\')
> To me, Python will interpret '' to '\\'. And the replace method
> will replace '\\' with '\'. So, the result will be 'Hello,
> \World'. But it's give me 'Hello, World'.
> The result I want form the code is 'Hello, \World'.
I am mystified by this question.
Yes '\\' may be one slash or two or something else more exotic.
But whatever it is (and its not a syntax error like with '\') it is something.
So how can replace(something,something) be anything other
than a no-op?
--
https://mail.python.org/mailman/listinfo/python-list
Re: One liners
On Saturday, December 7, 2013 10:26:04 PM UTC+5:30, Michael Torrie wrote:
> On 12/06/2013 08:27 PM, Roy Smith wrote:
> > Steven D'Aprano wrote:
> >> The ternary if is slightly unusual and unfamiliar
> > It's only unusual an unfamiliar if you're not used to using it :-)
> > Coming from a C/C++ background, I always found the lack of a ternary
> > expression rather limiting. There was much rejoicing in these parts
> > when it was added to the language relatively recently. I use them a lot.
> > On the other hand, I found list comprehensions to be mind-bogglingly
> > confusing when I first saw them (read: slightly unusual and unfamiliar).
> > It took me a long time to warm up to the concept. Now I love them.
> >> As for readability, I accept that ternary if is unusual compared to other
> >> languages, but it's still quite readable in small doses. If you start
> >> chaining them:
> >> result = a if condition else b if flag else c if predicate else d
> >> you probably shouldn't.
> > That I agree with (and it's just as true in C as it is in Python).
> > Just for fun, I took a look through the Songza code base. 66 kloc of
> > non-whitespace Python. I found 192 ternary expressions. Here's a few
> > of the more bizarre ones (none of which I consider remotely readable):
> > --
> > extracols = sorted(set.union(*(set(t.data.keys()) for t in tracks))) if
> > tracks else []
> This is a generator expressions, and ternary ifs are common and often
> needed in generator expressions.
> > --
> > c2s = compids2songs(set(targets.keys()) |
> > set.union(*map(set,targets.itervalues())),self.docmap,self.logger) if
> > targets else {}
> I suspect the ternary distracted you on this one. The ternary here is
> needed because if targets is None the expression fails. This part
> anyway is a common idiom.
> The rest is basically making a set (list of unique items only) of the
> combined keys and values from the "targets" dictionary. Now I'm not
> sure why the programmer needs do this, but nevertheless that's what it's
> doing. set.union is used because that can iterate over a list of sets,
> which is what the map returns. I suppose they could have done this, but
> it wouldn't be much clearer unless you knew what sets, map and
> itervalues do:
> if targets:
> c2s = compids2songs(
> set(targets.keys()) |
> set.union(*map(set,targets.itervalues())),
> self.docmap,
> self.logger )
> else:
>c2s = {}
> In any case the ternary operator isn't really the part you were
> complaining about. Personally if I needed to do this particular
> operation a lot (combine keys and values into a set), I'd write a
> function that returned the set. Still can't avoid the ternary, though,
> unless you made compids2songs a little smarter (and we don't know what
> compids2songs does with an empty set):
> def dict_keys_and_values_set (some_dict):
>return set(some_dict.keys()) |
> set.union(*map(set,some_dict.itervalues()))
> c2s = compids2songs( dict_keys_and_values_set(targets) ) if targets else {}
> or I suppose you could o this:
> c2s = {}
> if targets: c2s = compids2songs( dict_keys_and_values_set(targets) )
> Just a matter of taste.
> > --
> > code = 2 if (pmp3,paac)==(mmp3,maac) else 3 if any(x is None for x in
> > (pmp3,paac,mmp3,maac)) else 4
> > --
Just trying to rewrite that in a way which I try to use for long if-exprs
code = 2if (pmp3,paac)==(mmp3,maac) else
3if any(x is None for x in (pmp3,paac,mmp3,maac)) else
4
> This one probably could stand to be reworked for sure! A standard if
> block would be much clearer. Definitely an example of a programmer
> thinking he was clever... maybe a git bisect could identify the author
> and we can shame him.
The logic for writing (and hopefully reading) it this way is like this:
In math we often have equations that are defined by cases -- typically typeset
with a large curly bracket. Those else's hanging at the end are to be read as
a signal to read this whole expr and though under a big curly brace.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Saturday, December 7, 2013 3:46:02 PM UTC+5:30, wxjm...@gmail.com wrote: > Rusi: > "unicode as a medium is universal in the same way that > ASCII used to be" > Probably, you do not realize deeply how this sentence > is correct. Unicode and ascii are constructed in the > same way. It has not even to do with "characters", but > with mathematics. On the contrary, I'd say we have some rather interesting 'characters' out here. > It is on this level the FSR fails. It is mathematically > wrong by design! Now thats an even more interesting statement. Only not sure what it means Here are some attempts It is wrong therefore unmathematical It is designed so its wrong It is mathematical so its undesigned Any Ive missed?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Saturday, December 7, 2013 7:54:50 AM UTC+5:30, Ned Batchelder wrote: > On 12/6/13 8:03 AM, rusi wrote: > > Leaving aside whose fault this is (very likely buggy google groups), > > this mojibaking cannot happen if the assumption "All text is ASCII" > > were to uniformly hold. > > Of course with unicode also this can be made to not happen, but that > > is fragile and error-prone. And that is because ASCII (not extended) > > is ONE thing in a way that unicode is hopelessly a motley inconsistent > > variety. > You seem to be suggesting that we should stick to ASCII. There are of > course languages that need more than just the Latin alphabet. How would > you suggest we support them? Or maybe I don't understand? Heh! Yes I guess that can be read into what I was saying. Practically: I dont see that as an option or that the question of going back to ASCII even arises. I was talking more philosophically/historically. Up until the time of Unix a file for example was a structured heavy-duty concept motivated by entirely technological considerations: http://en.wikipedia.org/wiki/Data_set_%28IBM_mainframe%29 By simplifying that into the modern concept of file -- just a stream of bytes -- and allowing the puns: byte string = char list = text some elegant systems could be made with people having 'beautiful thoughts:' Everything that could be stored anywhere -- core or disk -- being bytes one could go to the next stage and pass around these bytes between processes. And so we get the elegant -- pipeline -- beauty of Unix scripts. Of course there was a catch (Isn't there always?): Things that did not fit in with this philosophy -- eg clicks of a mouse, bits on display -- were modelled badly or not at all. Not-at-all: CLI Badly: Monstrosity called X And this explains some of the cultural kinks of our field: Unix guys invariably think of CLIs as natural and obvious whereas GUIs are just wasteful eye-candy. [Yours truly is one of those old geezers who does not know how to write a GUI to save his life. Almost normal in the Unix world except that he's not proud of it] Windows/Mac people do not suffer these delusions but then they dont think of programming as natural or obvious at all. Ive often been amused at windows folk: They dont think of Word as a program. Rather docs are things that magically open when clicked :-) Brings me to the point I was trying to make (got side-tracked by the failure of a character to roundtrip between me and Roy -- Im none the wiser why) The ASCII = Text = Unicode (non)equation is a relatively minor point. The more central point is that humans use and need more than just words to communicate. By straitjacketing communication into the thin channel of text we are severely impoverishing ourselves. We communicate with systems with programs that are unstructured text-files even though programs are conceptually highly structured entities. Likewise we communicate with each other by this obscenely obsolete textual mode that I am using right now when rich text formats have been available for decades. Some of my more detailed writings on this: http://blog.languager.org/2013/09/poorest-computer-users-are-programmers.html http://blog.languager.org/2012/10/html-is-why-mess-in-programming-syntax.html -- https://mail.python.org/mailman/listinfo/python-list
Re: ASCII and Unicode [was Re: Managing Google Groups headaches]
On Saturday, December 7, 2013 8:11:45 AM UTC+5:30, Chris Angelico wrote: > On Sat, Dec 7, 2013 at 1:33 PM, rusi wrote: > > That seems to suggest that something is not right with the python > > mailing list config. No?? > If in doubt, blame someone else, eh? > I'd first check what your browser's actually sending. Firebug will > help there. See if your form fill-out is encoded as UTF-8 or CP-1252. > That's the first step. If you give me some tip where to look, I'll do that. But I dont see what this has to do with forms. Everything in the python archive (not just my posts) show as Win 1252 [I checked about 6] Every other page that I checked (most nothing to do with python list, GG etc) show UTF-8. [I checked about 5] None of these checkings had forms to be filled. -- https://mail.python.org/mailman/listinfo/python-list
Re: ASCII and Unicode [was Re: Managing Google Groups headaches]
On Saturday, December 7, 2013 12:30:18 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 06 Dec 2013 05:03:57 -0800, rusi wrote:
> > Evidently (and completely inadvertently) this exchange has just
> > illustrated one of the inadmissable assumptions:
> > "unicode as a medium is universal in the same way that ASCII used to be"
> Ironically, your post was not Unicode.
> Seriously. I am 100% serious.
> Your post was sent using a legacy encoding, Windows-1252, also known as
> CP-1252, which is most certainly *not* Unicode. Whatever software you
> used to send the message correctly flagged it with a charset header:
> Content-Type: text/plain; charset=windows-1252
> Alas, the software Roy Smith uses, MT-NewsWatcher, does not handle
> encodings correctly (or at all!), it screws up the encoding then sends a
> reply with no charset line at all. This is one bug that cannot be blamed
> on Google Groups -- or on Unicode.
> > I wrote a number of ellipsis characters ie codepoint 2026 as in:
> Actually you didn't. You wrote a number of ellipsis characters, hex byte
> \x85 (decimal 133), in the CP1252 charset. That happens to be mapped to
> code point U+2026 in Unicode, but the two are as distinct as ASCII and
> EBCDIC.
> > Somewhere between my sending and your quoting those ellipses became the
> > replacement character FFFD
> Yes, it appears that MT-NewsWatcher is *deeply, deeply* confused about
> encodings and character sets. It doesn't just assume things are ASCII,
> but makes a half-hearted attempt to be charset-aware, but badly. I can
> only imagine that it was written back in the Dark Ages where there were a
> lot of different charsets in use but no conventions for specifying which
> charset was in use. Or perhaps the author was smoking crack while coding.
> > Leaving aside whose fault this is (very likely buggy google groups),
> > this mojibaking cannot happen if the assumption "All text is ASCII" were
> > to uniformly hold.
> This is incorrect. People forget that ASCII has evolved since the first
> version of the standard in 1963. There have actually been five versions
> of the ASCII standard, plus one unpublished version. (And that's not
> including the things which are frequently called ASCII but aren't.)
> ASCII-1963 didn't even include lowercase letters. It is also missing some
> graphic characters like braces, and included at least two characters no
> longer used, the up-arrow and left-arrow. The control characters were
> also significantly different from today.
> ASCII-1965 was unpublished and unused. I don't know the details of what
> it changed.
> ASCII-1967 is a lot closer to the ASCII in use today. It made
> considerable changes to the control characters, moving, adding, removing,
> or renaming at least half a dozen control characters. It officially added
> lowercase letters, braces, and some others. It replaced the up-arrow
> character with the caret and the left-arrow with the underscore. It was
> ambiguous, allowing variations and substitutions, e.g.:
> - character 33 was permitted to be either the exclamation
> mark ! or the logical OR symbol |
> - consequently character 124 (vertical bar) was always
> displayed as a broken bar ¦, which explains why even today
> many keyboards show it that way
> - character 35 was permitted to be either the number sign # or
> the pound sign £
> - character 94 could be either a caret ^ or a logical NOT ¬
> Even the humble comma could be pressed into service as a cedilla.
> ASCII-1968 didn't change any characters, but allowed the use of LF on its
> own. Previously, you had to use either LF/CR or CR/LF as newline.
> ASCII-1977 removed the ambiguities from the 1967 standard.
> The most recent version is ASCII-1986 (also known as ANSI X3.4-1986).
> Unfortunately I haven't been able to find out what changes were made -- I
> presume they were minor, and didn't affect the character set.
> So as you can see, even with actual ASCII, you can have mojibake. It's
> just not normally called that. But if you are given an arbitrary ASCII
> file of unknown age, containing code 94, how can you be sure it was
> intended as a caret rather than a logical NOT symbol? You can't.
> Then there are at least 30 official variations of ASCII, strictly
> speaking part of ISO-646. These 7-bit codes were commonly called "ASCII"
> by their users, despite the differences, e.g. replacing the dollar sign $
> with the international currency sign ¤, or replacing the left brace
> { with the letter s with caron š.
> One consequence of this is that the MIME type for ASCII text is call
Re: using ffmpeg command line with python's subprocess module
On Friday, December 6, 2013 10:11:04 PM UTC+5:30, MRAB wrote: > On 06/12/2013 15:34, Steven D'Aprano wrote: > > On Fri, 06 Dec 2013 06:52:48 -0800, iMath wrote: > >> yes ,I am a native Chinese speaker.I always post question by Google > >> Group not through email ,is there something wrong with it ? your > >> english is a little strange to me . > > Mark is writing in fake old-English style, the way people think English > > was spoken a thousand years ago. I don't know why he did that. Perhaps he > > thought it was amusing. > [snip] > You're exaggerating. It's more like 500 years ago. :-) I was going to say the same until I noticed the "the way people think English was spoken..." That makes it unarguable -- surely there are some people who (wrongly) think so? -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
On Friday, December 6, 2013 9:55:54 PM UTC+5:30, Mark Lawrence wrote: > On 06/12/2013 16:19, rusi wrote: > > So someone please update that page! > This is a community so why don't you? Ok done (at least a first draft) I was under the impression that anyone could not edit -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
On Friday, December 6, 2013 9:23:47 PM UTC+5:30, Mark Lawrence wrote: > On 06/12/2013 15:34, Steven D'Aprano wrote: > > (if I remember correctly) I think Mark also > > > sometimes posts a link to managing Google Groups. > > > > > You do, and here it is https://wiki.python.org/moin/GoogleGroupsPython That link needs updating. Even if my almost-automatic correction methods are not considered kosher for some reason or other, the thing that needs to go in there is that GG has TWO problems 1. Blank lines 2. Long lines That link only describes 1. Roy's yesterday's post in "Packaging a proprietary python library" says: > I, and Rusi, know enough, and take the effort, to overcome its > shortcomings doesn't change that. But in fact his post takes care of 1 not 2. In all fairness I did not know that 2 is a problem until rurpy pointed it out recently and was not correcting it. In fact, I'd take the trouble to make the lines long assuming that clients were intelligent enough to fit it properly into whatever was the current window!!! So someone please update that page! -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
On Friday, December 6, 2013 8:42:02 PM UTC+5:30, Mark Lawrence wrote: > The English I used was archaic, please ignore it :) "Archaic" is almost archaic "Old" is ever-young :D -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
On Friday, December 6, 2013 8:22:48 PM UTC+5:30, iMath wrote: > 在 2013年12月6日星期五UTC+8下午5时23分59秒，Mark Lawrence写道： > > On 06/12/2013 06:23, iMath wrote: > > Dearest iMath, wouldst thou be kind enough to partake of obtaining some > > type of email client that dost not sendeth double spaced data into this > > most illustrious of mailing lists/newsgroups. Thanking thee for thine > > participation in my most humble of requests. I do remain your most > > obedient servant. > yes ,I am a native Chinese speaker.I always post question by Google Group not > through email ,is there something wrong with it ? Yes but its easily correctable I recently answered this question to another poster here https://groups.google.com/forum/#!searchin/comp.lang.python/rusi$20google$20groups|sort:date/comp.lang.python/C51hEvi-KbY/KSeaMFoHtcIJ -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Friday, December 6, 2013 7:18:19 PM UTC+5:30, Chris Angelico wrote: > On Sat, Dec 7, 2013 at 12:32 AM, rusi wrote: > > I guess we are using 'structured' in different ways. All I am saying > > is that mediawiki which seems to present as html, actually stores its > > stuff as SQL -- nothing more or less structured than the schemas here: > > http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Database_and_text_storage > Yeah, but the structure is all about the metadata. Ok (I'd drop the 'all') > Ultimately, there's one single text field containing the entire content Right > as you would see it in the page editor: wiki markup in straight text. Aha! There you are! Its 'page editor' here and not the html which 'display source' (control-u) which a browser would show. And wikimedia is the software that mediates. The usual direction (seen by users of wikipedia) is that wikimedia takes this text, along with the other unrelated (metadata?) seen around -- sidebar, tabs etc, css settings and munges it all into html The other direction (seen by editors of wikipedia) is that you edit a page and that page and history etc will show the changes, reflecting the fact that the SQL content has changed. > MediaWiki uses an SQL database to store that lump of text, but > ultimately the relationship is between wikitext and HTML, no SQL > involvement. Dunno what you mean. Every time someone browses wikipedia, things are getting pulled out of the SQL and munged into the html (s)he sees. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Friday, December 6, 2013 6:49:04 PM UTC+5:30, Chris Angelico wrote: > On Sat, Dec 7, 2013 at 12:03 AM, rusi wrote: > > SQL databases (assuming thats the mediawiki backend) is another -- ok for > > data-structuring bad for presentation. > No, SQL databases don't store structured text. MediaWiki just stores a > single blob (not in the database sense of that word) of text. I guess we are using 'structured' in different ways. All I am saying is that mediawiki which seems to present as html, actually stores its stuff as SQL -- nothing more or less structured than the schemas here: http://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Database_and_text_storage -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Friday, December 6, 2013 1:06:30 PM UTC+5:30, Roy Smith wrote: > Rusi wrote: > > On Thursday, December 5, 2013 6:28:54 AM UTC+5:30, Roy Smith wrote: > > > The real problem with web forums is they conflate transport and > > > presentation into a single opaque blob, and are pretty much universally > > > designed to be a closed system. Mail and usenet were both engineered to > > > make a sharp division between transport and presentation, which meant it > > > was possible to evolve each at their own pace. > > > Mostly that meant people could go off and develop new client > > > applications which interoperated with the existing system. But, it also > > > meant that transport layers could be switched out (as when NNTP > > > gradually, but inexorably, replaced UUCP as the primary usenet transport > > > layer). > > There is a deep assumption hovering round-about the above -- what I > > will call the 'Unix assumption(s)'. > It has nothing to do with Unix. The separation of transport from > presentation is just as valid on Windows, Mac, etc. > > But before that, just a check on > > terminology. By 'presentation' you mean what people normally call > > 'mail-clients': thunderbird, mutt etc. And by 'transport' you mean > > sendmail, exim, qmail etc etc -- what normally are called > > 'mail-servers.' Right?? > Yes. > > Assuming this is the intended meaning of the terminology (yeah its > > clearer terminology than the usual and yeah Im also a 'Unix-guy'), > > here's the 'Unix-assumption': > > - human communication� > > (is not very different from) > > - machine communication� > > (can be done by) > > - text� > > (for which) > > - ASCII is fine� > > (which is just) > > - bytes� > > (inside/between byte-memory-organized) > > - von Neumann computers > > To the extent that these assumptions are invalid, the 'opaque-blob' > > may well be preferable. > I think you're off on the wrong track here. This has nothing to do with > plain text (ascii or otherwise). It has to do with divorcing how you > store and transport messages (be they plain text, HTML, or whatever) > from how a user interacts with them. Evidently (and completely inadvertently) this exchange has just illustrated one of the inadmissable assumptions: "unicode as a medium is universal in the same way that ASCII used to be" I wrote a number of ellipsis characters ie codepoint 2026 as in: - human communication… (is not very different from) - machine communication… Somewhere between my sending and your quoting those ellipses became the replacement character FFFD > > - human communication� > > (is not very different from) > > - machine communication� Leaving aside whose fault this is (very likely buggy google groups), this mojibaking cannot happen if the assumption "All text is ASCII" were to uniformly hold. Of course with unicode also this can be made to not happen, but that is fragile and error-prone. And that is because ASCII (not extended) is ONE thing in a way that unicode is hopelessly a motley inconsistent variety. With unicode there are in-memory formats, transportation formats eg UTF-8, strange beasties like FSR (which then hopelessly and inveterately tickle our resident trolls!) multi-layer encodings (in html), BOMS and unnecessary/inconsistent BOMS (in microsoft-notepad). With ASCII, ASCII is ASCII; ie "ABC" is 65,66,67 whether its in-core, in-file, in-pipe or whatever. Ok there are a few wrinkles to this eg. the null-terminator in C-strings. I think this is the exception to the rule that in classic Unix, ASCII is completely inter-operable and therefore a universal data-structure for inter-process or inter-machine communication. It is this universal data structure that makes classic unix pipes and filters possible and easy (of which your separation of presentation and transportation is just one case). Give it up and the composability goes with it. Go up from the ASCII -> Unicode level to the plain-text -> hypertext (aka html) level and these composability problems hit with redoubled force. > Take something like Wikipedia (by which, I really mean, MediaWiki, which > is the underlying software package). Most people think of Wikipedia as > a web site. But, there's another layer below that which lets you get > access to the contents of articles, navigate all the rich connections > like category trees, and all sorts of metadata like edit histories. > Which means, if I wanted to (and many examples of this exist), I can > write my own client which presents the same information in different > ways. Not sure whats your point. Html is a universal data-structuring format -- ok for presentation, bad for data-structuring SQL databases (assuming thats the mediawiki backend) is another -- ok for data-structuring bad for presentation. Mediawiki mediates between the two formats. Beyond that I lost you... what are you trying to say?? -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, December 5, 2013 4:17:11 AM UTC+5:30, Cameron Simpson wrote: > On 03Dec2013 17:39, rusi wrote: > > On Wednesday, December 4, 2013 6:10:05 AM UTC+5:30, Cameron Simpson wrote: > > > My first act on joining any mailing list is to download the entire > > > archive into my local mail store. I have a script for this, for > > > mailman at least. > > and you happen to own >1 thingys that have general computing > > functionality -- phones, laptops, desktops, etc -- do you sync > > all your mailing-lists with all of them? > No. I'm using a laptops my primary host, and it has the mailing > lists (and all my email). It is usually on and fetches and files > my email; it also forwards _specific_ stuff to a separate mail > account accessed by my phone. > I used to use a home server, but the remote access, while fairly > transparent (script to "ssh then run mutt"), was irritating. And > when I didn't have remote access, very very irritating. > So I'm choosing the better environment with my email local to the laptop and > a select copy of important things (work and friends) copied to an account for > my phone. > [...] > > And inspite of all that it still sometimes happens that one has > > to work on a 'machine' that is not one's own. What then? > Fingers crossed the important stuff gets to my phone. If urgent I > can reply from that, and I'm somewhat up to date on what I care > about. The phone also has (disabled) access to my primary mail spool > for circumstances when the laptop is offline. When online, the > laptop empties that spool ad forwards particulars. When offline, I > can consult what's queuing up. > > The unfortunate and inexorable conclusion is that when the > > (wo)man <-> computer relation goes from 1-1 to 1-many, data and > > functionality will move away from 'own-machine' to the cloud. > > Will the data be subject to privacy-abuse and worse? Sure > > Will the functionality be as good as something one can fine-tune > > on one's own computer? heck no! > I'm striving to resist that for now. Privacy. Security. Dependence > on others' hardware and (not mine => wrong!) technical choices of > software. Thanks Cameron. I am not sure how to parse the last sentence but on the whole thanks for a fair balanced and honest review. I think I have similar sentiments, viz. I am not one to gush about the latest gizmodic blissiness, however whenever Ive resisted and been a late adopter -- color monitor, laptop, cellphone, credit card etc etc -- in the end Ive had to move with the time and not been better-off for my earlier resistance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, December 5, 2013 6:28:54 AM UTC+5:30, Roy Smith wrote: > Rich Kulawiec wrote: > > Yes, I'm > > aware of web forums: I've used hundreds of them. They suck. They ALL > > suck, they just all suck differently. I could spend the next several > > thousand lines explaining why, but instead I'll just abbreviate: they > > don't handle threading, they don't let me use my editor of choice, > > they don't let me build my own archive that I can search MY way including > > when I'm offline, they are brittle and highly vulnerable to abuse > > and security breaches, they encourage worst practices in writing > > style (including top-posting and full-quoting), they translate poorly > > to other formats, they are difficult to archive, they're even more > > difficult to migrate (whereas Unix mbox format files from 30 years ago > > are still perfectly usable today), they aren't standardized, they > > aren't easily scalable, they're overly complex, they don't support > > proper quoting, they don't support proper attribution, they can't > > be easily forwarded, they...oh, it just goes on. > The real problem with web forums is they conflate transport and > presentation into a single opaque blob, and are pretty much universally > designed to be a closed system. Mail and usenet were both engineered to > make a sharp division between transport and presentation, which meant it > was possible to evolve each at their own pace. > Mostly that meant people could go off and develop new client > applications which interoperated with the existing system. But, it also > meant that transport layers could be switched out (as when NNTP > gradually, but inexorably, replaced UUCP as the primary usenet transport > layer). There is a deep assumption hovering round-about the above -- what I will call the 'Unix assumption(s)'. But before that, just a check on terminology. By 'presentation' you mean what people normally call 'mail-clients': thunderbird, mutt etc. And by 'transport' you mean sendmail, exim, qmail etc etc -- what normally are called 'mail-servers.' Right?? Assuming this is the intended meaning of the terminology (yeah its clearer terminology than the usual and yeah Im also a 'Unix-guy'), here's the 'Unix-assumption': - human communication… (is not very different from) - machine communication… (can be done by) - text… (for which) - ASCII is fine… (which is just) - bytes… (inside/between byte-memory-organized) - von Neumann computers To the extent that these assumptions are invalid, the 'opaque-blob' may well be preferable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Packaging a proprietary Python library for multiple OSs
On Thursday, December 5, 2013 3:44:50 PM UTC+5:30, Michael Herrmann wrote: > Hi everyone, > > I am developing a proprietary Python library. The library is currently > Windows-only, and I want to also make it available for other platforms (Linux > & Mac). I'm writing because I wanted to ask for your expert opinion on how to > best do this. Wheel is the upcoming standard I think. http://www.python.org/dev/peps/pep-0427/ 1. It would be dishonest to remove the 'upcoming' 2. It would also be dishonest if you thought I know anything about the subject :-) 3. https://groups.google.com/forum/#!forum/python-virtualenv may be a better place to ask -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Thursday, December 5, 2013 8:13:49 AM UTC+5:30, Ian wrote: > On Wed, Dec 4, 2013 at 3:09 AM, rusi wrote: > > On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: > >> On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > >> > Its a more fundamental problem than that: > >> > It emerges from the OP's second post) that he wants '-' in the > >> > attributes. > >> > Is that all? > >> > > >> > Where does this syntax-enlargement stop? Spaces? Newlines? > >> > >> At non-strings. > >> > >> >>> setattr(foo, 21+21, 42) > >> Traceback (most recent call last): > >> File "", line 1, in > >> TypeError: attribute name must be string, not 'int' > > > > Not sure what's your point. > > There was no point. My comment was only meant to be amusing. Duh! Im dense! -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 6:02:18 PM UTC+5:30, Antoon Pardon wrote: > Op 04-12-13 13:01, rusi schreef: > > On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: > >> Op 04-12-13 11:09, rusi schreef: > >>> I used the spaces case to indicate the limit of chaos. > >>> Other characters (that > >>> already have uses) are just as problematic. > >> > >> I don't agree with the latter. As it is now python can make the > >> distinction between > >> > >> from A import Band fromAimportB. > >> > >> I see no a priori reason why this should be limited to letters. A > >> language designer might choose to allow a bigger set of characters > >> in identifiers like '-', '+' and others. In that case a-b would be > >> an identifier and a - b would be the operation. Just as in python > >> fromAimportB is an identifier and from A import B is an import > >> statement. > > > > Im not sure what you are saying. > > Sure a language designer can design a language differently from python. > > I mentioned lisp. Cobol is another behaving exactly as you describe. > > > > My point is that when you do (something like) that, you will need to change > > the > > lexical and grammatical structure of the language. And this will make > > for rather far-reaching changes ALL OVER the language not just in > > what-follows-dot. > > No you don't need to change the lexical and grammatical structure of > the language. Changing the characters allowed in identifiers, is not a > change in lexical structure. The only difference in lexical structuring > would be that '-', '>=' and other similars symbols would have to be > treated like keyword like 'from', 'as' etc instead of being recognizable > by just being present. Well I am mystified… Consider the string a-b in a program text. A Cobol or Lisp system sees this as one identifier. Python, C (and most modern languages) see this ident, operator, ident. As I understand it this IS the lexical structure of the language and the lexer is the part that implements this: - in cobol/lisp keeping it as one - in python/C breaking it into 3 Maybe you understand in some other way the phrase "lexical structure"? > And the grammatical structure of the language wouldn't change at all. > Sure a-b would now be an identifier and not an operation but that is > of no concern for the parser. About grammar maybe what you are saying will hold: presumably if the token-set is the same, one could keep the same grammar, with the differences being entirely inter-lexeme ones. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 3:59:06 PM UTC+5:30, Antoon Pardon wrote: > Op 04-12-13 11:09, rusi schreef: > > I used the spaces case to indicate the limit of chaos. > > Other characters (that > > already have uses) are just as problematic. > > I don't agree with the latter. As it is now python can make the > distinction between > > from A import Band fromAimportB. > > I see no a priori reason why this should be limited to letters. A > language designer might choose to allow a bigger set of characters > in identifiers like '-', '+' and others. In that case a-b would be > an identifier and a - b would be the operation. Just as in python > fromAimportB is an identifier and from A import B is an import > statement. Im not sure what you are saying. Sure a language designer can design a language differently from python. I mentioned lisp. Cobol is another behaving exactly as you describe. My point is that when you do (something like) that, you will need to change the lexical and grammatical structure of the language. And this will make for rather far-reaching changes ALL OVER the language not just in what-follows-dot. IOW: I dont agree that we have a disagreement :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 4:03:14 PM UTC+5:30, Chris Angelico wrote: > On Wed, Dec 4, 2013 at 9:09 PM, rusi wrote: > > OP wants attribute identifiers like > > outer_fieldset-inner_fieldset-third_field. > > Say I have a python expression: > > obj.outer_fieldset-inner_fieldset-third_field > > I don't think so. What the OP asked for was: > > my_object.'valid-attribute-name-but-not-valid-identifier' > > Or describing it another way: A literal string instead of a token. This is just pushing the issue one remove away. Firstly a literal string is very much a token -- lexically. Now consider the syntax as defined by the grammar. Let Ident = Set of strings* that are valid python identifiers -- something like [a-zA-Z][a-zA-Z0-9]* Let Exp = Set to strings* that are python expressions * Note that I am using string from the language implementers pov not language user ie the python identifier var is the implementers string "var" whereas the python string literal "var" is the implementer's string "\"var\"" Now clearly Ident is a proper subset of Exp. Now what is the proposal? You want to extend the syntactically allowable a.b set. If the b's can be any arbitrary expression we can have var.fld(1,2) with the grammatical ambiguity that this can be (var.fld)(1,2) -- the usual interpretation Or var.(fld(1,2)) -- the new interpretation -- ie a computed field name. OTOH if you say superset of Ident but subset of Exp, then we have to determine what this new limbo set is to be. ie what is the grammatical category of 'what-follows-a-dot' ?? Some other-language notes: 1. In C there is one case somewhat like this: #include "string" the "string" cannot be an arbitrary expression as the rest of C. But then this is not really C but the C preprocessor 2. In lisp the Ident set is way more permissive than in most languages -- allowing operators etc that would be delimiters in most languages. If one wants to go even beyond that and include say spaces and parenthesis -- almost the only delimiters that lisp has -- one must write |ident with spaces| ie for identifiers the bars behave somewhat like strings' quote marks. Because the semantics of identifiers and strings are different -- the lexical structures need to reflect that difference -- so you cannot replace the bars by quotes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 2:27:28 PM UTC+5:30, Ian wrote: > On Tue, Dec 3, 2013 at 11:31 PM, rusi wrote: > > Its a more fundamental problem than that: > > It emerges from the OP's second post) that he wants '-' in the attributes. > > Is that all? > > > > Where does this syntax-enlargement stop? Spaces? Newlines? > > At non-strings. > > >>> setattr(foo, 21+21, 42) > Traceback (most recent call last): > File "", line 1, in > TypeError: attribute name must be string, not 'int' Not sure what's your point. OP wants attribute identifiers like outer_fieldset-inner_fieldset-third_field. Say I have a python expression: obj.outer_fieldset-inner_fieldset-third_field It can (in the proposed extension) be parsed as above, or as: obj.outer_fieldset - inner_fieldset-third_field the first hyphen being minus and the second being part of the identifier. How do we decide which '-' are valid identifier components -- hyphens and which minus-signs? So to state my point differently: The grammar of python is well-defined It has a 'sub-grammar' of strings that is completely* free-for-all ie just about anything can be put into a string literal. The border between the orderly and the wild world are the quote-marks. Remove that border and you get complete grammatical chaos. [Maybe I should have qualified my reference to 'spaces'. Algol-68 allowed spaces in identifiers (for readability!!) The result was chaos] I used the spaces case to indicate the limit of chaos. Other characters (that already have uses) are just as problematic. * Oh well there are some restrictions like quotes need to be escaped, no newlines etc etc -- minor enough to be ignored. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why is there no natural syntax for accessing attributes with names not being valid identifiers?
On Wednesday, December 4, 2013 11:15:05 AM UTC+5:30, Tim Roberts wrote: > Piotr Dobrogost wrote: > > > >Attribute access syntax being very concise is very often preferred > >to dict's interface. > > It is not "very concise". It is slightly more concise. > > x = obj.value1 > x = dct['value1'] > > You have saved 3 keystrokes. That is not a significant enough savings to > create new syntax. Remember the Python philosophy that there ought to be > one way to do it. Its a more fundamental problem than that: It emerges from the OP's second post) that he wants '-' in the attributes. Is that all? Where does this syntax-enlargement stop? Spaces? Newlines? -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Wednesday, December 4, 2013 6:10:05 AM UTC+5:30, Cameron Simpson wrote: > > Dennis Lee Bieber writes: > > > [NNTP] clients provide full-fledged editors > >and conversely full-fledged editors provide > >NNTP clients > GNU Emacs is a LISP operating system disguised as a word processor. > - Doug Mohney, in comp.arch In a similar vein, most phones nowadays are just computers with a pocket-size form-factor and some wireless networking. So when you say… > My first act on joining any mailing list is to download the entire > archive into my local mail store. I have a script for this, for > mailman at least. and you happen to own >1 thingys that have general computing functionality -- phones, laptops, desktops, etc -- do you sync all your mailing-lists with all of them? I know friends who have installed a home-data-store… [Ive been resisting getting something like a NAS because each new thingabob I own is one more thing to maintain. I also know from past experience that such luddite battles are in the end always lost -- Im no technophile but I expect to live and die a techie] And inspite of all that it still sometimes happens that one has to work on a 'machine' that is not one's own. What then? The unfortunate and inexorable conclusion is that when the (wo)man <-> computer relation goes from 1-1 to 1-many, data and functionality will move away from 'own-machine' to the cloud. Will the data be subject to privacy-abuse and worse? Sure Will the functionality be as good as something one can fine-tune on one's own computer? heck no! But in the end, uniform access will trump all that -- compare the number of vi+emacs+eclipse users with google-doc users… So to come back full-circle: Earlier (your quote paraphrased) Emacs is a full-blown OS -- only lacks a good editor. Now: replace 'emacs' with 'firefox'. -- https://mail.python.org/mailman/listinfo/python-list
Re: The input and output is as wanted, but why error?
On Tuesday, December 3, 2013 9:18:43 PM UTC+5:30, geez...@gmail.com wrote: > I am trying to solve this problem: > > http://codeforces.com/problemset/problem/71/A > > The input and output is as wanted, but my answer keep rejected, here is my > source code http://txt.do/1smv > > Please, I need help. I suggest you take your problem one step at a time, like this: 1. You need to convert a string like "localization" to "l10n" Write a function that takes strings like "localization" and RETURNS strings like "l10n". The function SHOULD NOT use print. 2. Now you need to convert a list of strings like ["word", "localization", "internationalization", "pneumonoultramicroscopicsilicovolcanoconiosis" ] to a list like ["word", "l10n", "i18n", "p43s"] You can use the above function (1). NO PRINTS 3. Use the function in 2 above to solve the problem. Here you may use print -- https://mail.python.org/mailman/listinfo/python-list
Re: extracting a heapq in a for loop - there must be more elegant solution
On Tuesday, December 3, 2013 5:48:59 PM UTC+5:30, Helmut Jarausch wrote: > Hi, > > I'd like to extracted elements from a heapq in a for loop. > I feel my solution below is much too complicated. > How to do it more elegantly? > I know I could use a while loop but I don't like it. How about def in_sequence(h): for i in range(len(h)): yield heapq.heappop(h) Yeah its a bit fiddly: 1. i needed for for but not used 2. The range in the for loop -- normally a python 'smell' If python3 def ins3(h): yield from (heapq.heappop(h) for i in range(len(h))) -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Managing Google Groups headaches
On Tuesday, December 3, 2013 8:39:02 AM UTC+5:30, Michael Torrie wrote: > On 12/02/2013 06:43 PM, Roy Smith wrote: > > And this is surprising, why? > > Well back when Google was a young hip company they billed themselves as > a bunch of nerds making stuff for nerds. But yes we should have seen > this coming. So were Bill Gates and Jobs -- nerdy youths. We tend to not think them so because they are an earlier generation. -- https://mail.python.org/mailman/listinfo/python-list
Re: [OT] Managing Google Groups headaches
On Tuesday, December 3, 2013 7:13:03 AM UTC+5:30, Roy Smith wrote: > Michael Torrie wrote: > > I wish Google hadn't bought a lot of things. Seems like they bye up a > > lot of cool, nerd-centric apps and companies and then turned them into > > apps that do less and do it poorly, but in a slick way that appeals to > > the unwashed masses. And add "social" to it. Great for their bottom > > line, but horrible for those of us that actually use things as tools. > And this is surprising, why? Something floating around here (was it Ben Finney's footer??) went something like: We must expect it; else we would be surprised Put differently: One evidence of being awake (and not in dreamland) is surprise A directly related piece by Nicholas Carr http://www.theatlantic.com/magazine/archive/2008/07/is-google-making-us-stupid/306868/ Relevant at a deeper level is his "IT doesn't matter" http://www.roughtype.com/?p=644 We software professionals cannot agree with this and keep our self-respect/sanity/identity. However its true; so denial remains the only option. -- https://mail.python.org/mailman/listinfo/python-list
Re: using ffmpeg command line with python's subprocess module
On Tuesday, December 3, 2013 6:45:42 AM UTC+5:30, iMath wrote: > so is there any way to create a temporary file by Python here ? http://docs.python.org/2/library/tempfile.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Monday, December 2, 2013 7:34:33 PM UTC+5:30, Neil Cerutti wrote: > On 2013-12-02, Roy Smith wrote: > >> The current situation does force a lot of technology-focused > >> people, progammers in particular, into a low opinion of Google. > >> The crappy usenet portal is poor marketing. > > > > If you think, "The set of people who are still trying to use > > usenet groups for anything serious" is a lot of people, you > > don't understand the scale on which Google operates. > > It's probably hard to even visualize. I was dreaming about in an alternate surreal world… And now you guys have crashed me back to planet-earth-2013 !MEAN! -- https://mail.python.org/mailman/listinfo/python-list
Re: Checking Common File Types
On Monday, December 2, 2013 5:11:15 AM UTC+5:30, jade wrote:
> > To: pytho...@python.org
> > From: wlf...@ix.netcom.com
> > Subject: Re: Checking Common File Types
> > Date: Sun, 1 Dec 2013 18:23:22 -0500
> >
> > On Sun, 1 Dec 2013 18:27:16 +, jade declaimed the
> > following:
> >
> > >Hello,
> > >I'm trying to create a script that checks all the files in my 'downloaded'
> > >directory against common file types and then tells me how many of the
> > >files in that directory aren't either a GIF or a JPG file. I'm familiar
> > >with basic Python but this is the first time I've attempted anything like
> > >this and I'm looking for a little help or a point in the right direction?
> > >
> > >file_sigs = {'\xFF\xD8\xFF':('JPEG','jpg'), '\x47\x49\x46':('GIF','gif')}
> >
> > Apparently you presume the file extensions are inaccurate, as you are
> > digging into the files for signatures.
> >
> > >def readFile():filename = r'c:/temp/downloads' fh =
> > >open(filename, 'r') file_sig = fh.read(4) print '[*] check_sig()
> > >File:',filename #, 'Hash Sig:', binascii.hexlify(file_sig)
> >
> > Note: if you are hardcoding forward slashes, you don't need the raw
> > indicator...
> >
> > That said, what is "c:/temp/downloads"? You apparently are opening IT
> > as the file to be examined. Is it supposed to be a directory containing
> > many files, a file containing a list of files, ???
> >
> > What is "check_sig" -- it looks like a function you haven't defined --
> > but it's inside the quotes making a string literal that will never be
> > called anyway.
> >
> > If you are just concerned with one directory of files, you might want
> > to read the help file on the glob module, along with os.path
> > (join/splitext/etc). Or just string methods...
> >
> > >>> import glob
> > >>> import os.path
> > >>> TARGET = os.path.join(os.environ["USERPROFILE"],
> > ... "documents/BW-conversion/*")
> > >>> TARGET = os.path.join(os.environ["USERPROFILE"],
> > ... "documents/BW-conversion/*")
> > >>> files = glob.glob(TARGET)
> > >>> for fn in files:
> > ... fp, fx = os.path.splitext(fn)
> > ... print "File %s purports to be of type %s" % (fn, fx.upper())
> > ...
> > File C:\Users\Wulfraed\documents/BW-conversion\BW-1.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\BW-2.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\BW-3.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\BW-4.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\BWConv.html purports to be
> > of type .HTML
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b1.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b2.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b3.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b4.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b5.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_b6.jpg purports to be of
> > type .JPG
> > File C:\Users\Wulfraed\documents/BW-conversion\roo_col.jpg purports to be
> > of type .JPG
> > >>>
> > --
> > Wulfraed Dennis Lee Bieber AF6VN
> > wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
>
>
> Hi, thanks for all your replies. I realised pretty soon after I asked for
> help that I was trying to read the wrong amount of bytes and set about
> completely rewriting my code (after a coffee break)
>
> import sys, os, binascii
>
> def readfile():
>
>
> dictionary = {'474946':('GIF', 'gif'), 'ffd8ff':('JPEG', 'jpeg')}
> try:
> files = os.listdir('C:\\Temp\\downloads')
> for item in files:
> f = open('C:\\Temp\\downloads\\'+ item, 'r')
> file_sig = f.read(3)
> file_sig_hex = binascii.hexlify(file_sig)
>
> if file_sig_hex in dictionary:
> print item + ' is a image file, it is a ' + file_sig
>
> else:
> print item + ' is not an image file, it is' +file_sig
>
> print file_sig_hex
>
>
>
> except:
> print 'Error. Try again'
>
> finally:
> if 'f' in locals():
> f.close()
>
> def main():
>
> readfile()
>
> if __name__ == '__main__':
> main()
>
> As of right now my script prints out 'Error Try again' but when i comment out
> this part of the code;
>
> if file_sig_hex in dictionary:
> print item + ' is a image file' + dictionary
>
> else:
> print item + ' is not an image file, is it' +dictionary
>
>
>
> it
Re: Change a file type in Python?
On Sunday, December 1, 2013 8:52:03 AM UTC+5:30, Chris Angelico wrote: > On Sun, Dec 1, 2013 at 2:02 PM, rusi wrote: > > On Sunday, December 1, 2013 5:34:11 AM UTC+5:30, Eamonn Rea wrote: > >> Thanks for the help! > >> > >> Ok, I'll look into the mailing list. > > > > [Assuming you are using GG with firefox on linux] > > > > All you need to do is > > 1. Install 'Its all text' FF addon > > 2. Point the 'editor' of 'Its all text' to the below python script > > > > After that, a small new edit button will appear outside the text-box and > > its one-click solution > > What you're suggesting still doesn't wrap text properly, as > evidenced by your above over-long line. > > ChrisA Ok my bad. I offered a 1-click solution, but did 0 clicks :-) Strictly speaking one needs anywhere between one and two clicks for this to work properly. My profuse apologies for the improper and illegitimate round-down > Yeah I still think it's a lot easier to switch to a properly-working > system. Of course -- if 1.something clicks are too onerous, you are free not to use it :-) More seriously this discussion completely misses the point. I think we are dealing with 3 completely separable problems: [Slightly changing what I earlier wrote…] 1. Undesirable elements -- spam, troll and more exotic 2. Immature noobs -- literally or almost literally kids 3. Stupid technology -- in this case, GG The anti-GG crusade is getting pissed-off with 1 and/or 2 and then attacking 3. -- https://mail.python.org/mailman/listinfo/python-list
Re: Change a file type in Python?
On Sunday, December 1, 2013 5:34:11 AM UTC+5:30, Eamonn Rea wrote:
> Thanks for the help!
>
> Ok, I'll look into the mailing list.
[Assuming you are using GG with firefox on linux]
All you need to do is
1. Install 'Its all text' FF addon
2. Point the 'editor' of 'Its all text' to the below python script
After that, a small new edit button will appear outside the text-box and its
one-click solution
-Python Script--
#!/usr/bin/env python3
# As far as I know both python2 and 3 work
# Windows/Mac no idea :-)
# A script to drop-in as an editor for firefox addon "Its all text"
# It cleans up two google-group nuisances:
# 1. Useless blank lines
# 2. Excessively long lines
# No efforts at error reporting as stderr is not available in any
# easy way (I know) to firefox (other browsers?)
# To test separately:
# Compose a mail (preferably reply) in GG
# Copy-paste the stuff (maybe with some long lines added without the >)
# Run this script with that filename as argv[1]
from sys import argv
from re import sub
import re
# Clean double spacing
def cleands(s):
# Assumption: ASCII 025 (NAK) never occurs in input
s1 = sub("^> *\n> *$", "\025" , s , flags=re.M)
s2 = sub("^> *\n", "" , s1, flags=re.M)
s3 = sub("\025\n", ">\n" , s2, flags=re.M)
return s3
# Maximum length that (new) lines should attain
Maxlen = 75
# clean all long lines, s is the whole file/text
def cleanall_ll(s):
lines = (cleanll(l) for l in s.split("\n"))
return "\n".join(lines)
# clean one long line
def cleanll(line):
return ( line if line.startswith(">") else cleanll_rec(line) )
def cleanll_rec(line):
if len(line) <= Maxlen : return line
pos = line.rfind(" ", 0, Maxlen)
if pos == -1 : #Failed due to no spaces
return line
return line[0:pos] + "\n" + cleanll_rec(line[pos+1: ])
def clean(s):
return cleanall_ll(cleands(s))
def main():
with open(argv[1]) as f: s = f.read()
with open(argv[1], "w") as f: f.write(clean(s))
if __name__ == '__main__' :
main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Friday, November 29, 2013 12:07:29 AM UTC+5:30, rusi wrote: > On Thursday, November 28, 2013 11:59:13 PM UTC+5:30, Michael Torrie wrote: > > On 11/28/2013 10:23 AM, Ned Batchelder wrote: > > > Funny, I thought the sentiment of many here was, "let's just keep this > > > as a newsgroup, why do we need the mailing list also?" but I'll admit to > > > being confused about what people have been proposing for alternate > > > topologies. > > > > That may well be the majority sentiment here. I only state my opinion. > > > > Seems like 90% of the problems on this list come from the unchecked > > usenet side of things. Such as trolls or spam. For example a certain > > iron-skulled person who posted his whining rants and threats from half a > > dozen different addresses to the annoyance of all. Despite many calls > > to banish him from the list for his blatant disregard for list > > etiquette, with usenet it's just not possible. Although I'm sure some > > would argue that's a good thing to be unable to kick offenders off the list. > > Do you realize that that person was not using GG? > > IOW we are unfortunately conflating two completely unrelated things: > 1. GG has some technical problems which are fairly easy to solve > 2. All kinds of people hop onto the list. In addition to genuine ones there > are >spammers, trolls, dicks, nuts, philosophers, help-vampires etc etc. To add to that: 1. In this thread itself there is a quadruple-post 2. In an adjacent thread there is the mess due to html mail 3. Sometime ago there was a long argument around the old and unsettled: Reply vs Reply-all debate All these are due to NON use of GG. Does that mean everyone should use GG? Heck no! Just this: Technology will occasionally have problems and these can usually be solved technically. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, November 28, 2013 11:59:13 PM UTC+5:30, Michael Torrie wrote: > On 11/28/2013 10:23 AM, Ned Batchelder wrote: > > Funny, I thought the sentiment of many here was, "let's just keep this > > as a newsgroup, why do we need the mailing list also?" but I'll admit to > > being confused about what people have been proposing for alternate > > topologies. > > That may well be the majority sentiment here. I only state my opinion. > > Seems like 90% of the problems on this list come from the unchecked > usenet side of things. Such as trolls or spam. For example a certain > iron-skulled person who posted his whining rants and threats from half a > dozen different addresses to the annoyance of all. Despite many calls > to banish him from the list for his blatant disregard for list > etiquette, with usenet it's just not possible. Although I'm sure some > would argue that's a good thing to be unable to kick offenders off the list. Do you realize that that person was not using GG? IOW we are unfortunately conflating two completely unrelated things: 1. GG has some technical problems which are fairly easy to solve 2. All kinds of people hop onto the list. In addition to genuine ones there are spammers, trolls, dicks, nuts, philosophers, help-vampires etc etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Getting the Appdata Directory with Python and PEP?
On Thursday, November 28, 2013 9:41:30 PM UTC+5:30, Eamonn Rea wrote: > Oh, sorry, I'm new to how Google Groups works. I wonder why it lays it out > like that. Can it not just show quotes like the way that PHPbb does? > > I never thought of reading the source code, thanks! :-) > > Oh, and the last message is just spam :P Here's a solution https://groups.google.com/forum/#!topic/comp.lang.python/H4NZPk1HqbI You can skip the initial emacs suggestion and jump to the pure python one at end -- 18th post or so. -- https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
Here's a 1-click pure python solution.
As I said I dont know how to manage errors!
1. Put it in a file say cleangg.py and make it executable
2. Install it as the 'editor' for the "Its all text" firefox addon
3. Click the edit and you should get a cleaned out post
--
#!/usr/bin/env python3
from sys import argv
import re
from re import sub
def clean(s):
s1 = sub("^> *\n> *$", "¶", s, flags=re.M)
s2 = sub("^> *\n", "",s1, flags=re.M)
s3 = sub("¶\n",">\n", s2, flags=re.M)
return s3
def main():
print ("argv[1] %s" % argv[1])
with open(argv[1]) as f:
s = f.read()
with open(argv[1], "w") as f:
f.write(clean(s))
main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Managing Google Groups headaches
On Thursday, November 28, 2013 9:20:39 PM UTC+5:30, Alister wrote: > On Fri, 29 Nov 2013 02:08:17 +1100, Chris Angelico wrote: > > On Fri, Nov 29, 2013 at 2:04 AM, rusi wrote: > >> Its really quite unclear to me why GG is a problem if all the problems > >> of GG are obviated. > > Which is easier, fiddling around with your setup so you can post > > reasonably on Google Groups, or just getting a better client? With your > > setup, you have to drop out to another editor and press F9 for it to > > work. With pretty much any other newsreader on the planet, this works > > straight off, no setup necessary. > > I'm still going to advise people to stop using buggy rubbish. > > ChrisA > Whilst I agree with Chris A's main points I would at least say thankyou > for :- Well thanks for the thanks :-) > A) finding a solution that works for you. > B) Posting it so that others can try it to see if it works for them. > Perhaps the best option is for everybody to bombard Google with bug > reports (preferably typed with extra long lines & double spaced as that > is clearly what they are used to & we would not want to upset them would > we? ) If that has even a small likelihood of succeeding I heartily support it. My impression is its been done with no result -- Usenet is too fringe and obsolete a technology for Google to bother. On a different note your message has arrived 4 times. What client did you use? -- https://mail.python.org/mailman/listinfo/python-list
