Re: Python is going to be hard
On Thu, Sep 4, 2014 at 4:23 PM, Rustom Mody wrote: > A patient goes to hospital. The first thing the nurses do (even before the > doctor arrives) is to stick all kinds of tubes into... eyes, nose, ears and > other unmentionable places. The doctor arrives and orders a few more > invasions. > Some of these are for helping eg a saline drip to a dehydrated patient, mostly > they are for 'debugging' the patient -- what things are there in the blood > (etc) > that should not be or what is defcient that should be etc etc > > Would you consider it acceptable that when the patient is declared cured, > he/she is sent home with these tubes hanging out? > > Sure there are exceptions -- eg a patient needs a plaster/pacemaker etc. > As a rule he/she should be freed from all this. > > You seem to think a print hanging out of a program to be ok, normal. > I consider it exceptional. You keep saying that it's exceptional. You haven't really said why. It's the simplest form of "program produces output for the human to see", which all of your subsequent examples are more complicated versions of: > 1. Program is a gui -- There can be no meaningful prints, only > GUI-toolkit dialogs. (I actually disagree - several of my GUI programs have consoles for debug output - but that's a separate point.) GUI toolkit dialogs are inherently more complicated than simple print() calls, so they can be learned later. "See, this is how you print to a console. Now, if you do this, this, and this, you instead get a dialog." > 2. Program is a web-app -- It is painful and inefficient to generate > the html with prints. The correct approach is to use a templating engine The templating engine is just another more complicated form of output. Once again, learn the simple and fundamental first, and then add complexity - starting with small levels of complexity like "You are user %d of %d."%(user_num, concurrent_limit) and going up from there. > 3. Program is a classic unix filter. If it is doing something entirely trivial > -- eg cat -- it matters little how its written. If it is doing something > significant > it is best structured into IO and computation separated And how is the first of those going to be done? Somewhere, you need to do I/O, and that's going to involve something very like print. > 4. Programmer is a noob. You would start him on scripts. > I would start him in the REPL I would actually start on both. But if you're going to copy and paste a bunch of stuff to python-list and say "here's what's going wrong, can you help", it is MUCH easier if that's a script than an interactive session that might have had almost anything preceding it. > There is such a thing as law of primacy -- what is learnt first is remembered > most. And there are many important things when learning programming/python. > One of them is debugging. print is excellent for that. > > But there are more important things than that -- like structuring code and > using appropriate data structures. Putting print in the place of primacy > screws up that learning curve Okay. Here's the thing I most want people to remember: Make the program tell you stuff. Because that's more important as a debugging help than *anything* in the world. No matter how beautiful your data structure is, it's useless if you don't know how to get the program to tell you about it. You might like the idea of pure mathematical thinking, and that's fine as a theory. If you want to teach programming on a blackboard, go ahead, and use extremely functional style. Me, I've been tutoring several Python students over the past few weeks, and I want to see them get info back from the program. Using print() is perfect for them, and it won't be a bad thing in the future. Maybe it's ugly and messy and offends your theory-clean sensibilities, but it solves real-world problems. Practicality beats purity. Especially when it actually solves real problems that people pay money to get solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 10:33:38 AM UTC+5:30, Chris Angelico wrote: > On Thu, Sep 4, 2014 at 2:11 PM, Rustom Mody wrote: > > Is there some PEP filed called "Abolish print in python 4" ? > > I dont remember filing any such... > You screamed "NO PRINT" at us in the voice of Edna Mode. (At least, > that's how I imagined it being said. YMMV.) > > Perhaps you should think of the relevance (rather than the > > correctness) of your arguments Chris! Are you arguing > > 1. With me? > > If 1 then yeah I know when to use prints and when not > This. Then why are you advocating their non-use to new programmers? > Are you really saying print() is for experienced people only? Or, more > generally, that it should be possible for new programmers to do > absolutely all their coding at the REPL, never using any function with > side effects or mutating any state? (I was going to say "or using any > mutable objects", but since Python doesn't have tuple comprehensions, > you'd have to use lists. But if you never change what a list contains, > it comes to the same thing.) A patient goes to hospital. The first thing the nurses do (even before the doctor arrives) is to stick all kinds of tubes into... eyes, nose, ears and other unmentionable places. The doctor arrives and orders a few more invasions. Some of these are for helping eg a saline drip to a dehydrated patient, mostly they are for 'debugging' the patient -- what things are there in the blood (etc) that should not be or what is defcient that should be etc etc Would you consider it acceptable that when the patient is declared cured, he/she is sent home with these tubes hanging out? Sure there are exceptions -- eg a patient needs a plaster/pacemaker etc. As a rule he/she should be freed from all this. You seem to think a print hanging out of a program to be ok, normal. I consider it exceptional. At the level of expertise of the OP -- this thread starts with confusion about a for -- the foll. is totally irrelevant. However since you are bringing in heavy-duty examples like 'ray-tracing animation' lets see a few examples: 1. Program is a gui -- There can be no meaningful prints, only GUI-toolkit dialogs. 2. Program is a web-app -- It is painful and inefficient to generate the html with prints. The correct approach is to use a templating engine 3. Program is a classic unix filter. If it is doing something entirely trivial -- eg cat -- it matters little how its written. If it is doing something significant it is best structured into IO and computation separated 4. Programmer is a noob. You would start him on scripts. I would start him in the REPL > Because that is what I'm arguing against. New programmers and > experienced programmers alike need their code to produce output, and > return values are just one form of that. Excluding all other forms is > unnecessary. There is such a thing as law of primacy -- what is learnt first is remembered most. And there are many important things when learning programming/python. One of them is debugging. print is excellent for that. But there are more important things than that -- like structuring code and using appropriate data structures. Putting print in the place of primacy screws up that learning curve > > Is there some PEP filed called "Abolish print in python 4" ? > > I dont remember filing any such... > You screamed "NO PRINT" at us in the voice of Edna Mode. (At least, > that's how I imagined it being said. YMMV.) Dos and donts for adults and for children are different (at least in my part of the world) ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
Steven D'Aprano : > Marko Rauhamaa wrote: >> That's the classic Boolean algebraic notation. > > Says who? (Apart from you, obviously :-) Since when? I've never seen > it in *any* discussion of Boolean algebra. I have only run into George Boole, Boolean algebra and booleans in engineering textbooks (digital electronics, software programming). IIRC, they *always* used the multiplication and addition symbols. When studying symbolic logic, I never ran into that notation or Boole or Boolean algebra or booleans. For example, ∧ and ∨ are called connectors instead of operations. IOW, they are symbols of a language instead of functions. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
On Thu, Sep 4, 2014 at 9:39 AM, MRAB wrote:
> I occasionally think about a superset of JSON, called, say, "pyson" ...
> ah, name already taken! :-(
While I'm somewhat sympathetic to the concept, there are some parts of
your description that I disagree with. Am I misreading something? Are
there typos in the description and I'm making something out of
nothing?
> It would add tuples, delimited by (...), which are not used otherwise (no
> expressions):
>
> () => ()
> (0, ) => (0)
This seems odd. Part of JSON's convenience is that it's a subset of
JavaScript syntax, so you can just plop a block of JSON into a REPL
and it'll decode correctly. With PyON (or whatever you call it), it'd
be nice to have the same correspondence; for a start, I would strongly
encourage the "trailing comma is permitted" rule (so [1,2,3,] is
equivalent to [1,2,3]), and then I'd have the default encoding for a
single-element tuple include that trailing comma. If (0) is a
one-element tuple, you end up with a subtle difference between a PyON
decode and the Python interpreter, which is likely to cause problems.
It might even be worth actually mandating (not just encouraging) that
one-element tuples have the trailing comma, just to prevent that.
> The key of a dict could also be int, float, or tuple.
Yes! Yes! DEFINITELY do this!! Ahem. Calm down a little, it's not that
outlandish an idea...
> It could support other classes, and could handle named arguments.
>
> For example, sets:
>
> To encode {0, 1, 2):
Do you mean {0, 1, 2} here? I'm hoping you aren't advocating a syntax
that mismatches bracket types. That's only going to cause confusion.
> Look in encoder dict for encoder function with class's name ('set') and
> call it, passing object.
>
> Encoder returns positional and keyword arguments: [0, 1, 2] and {}.
>
> Output name, followed by encoded arguments in parentheses.
>
> Encoder for set:
>
> def encode_set(obj):
> return list(obj), {}
>
> To decode 'set(0, 1, 2)':
>
> Parse name: 'set'.
>
> Parse contents of parentheses: [0, 1, 2] and {}.
>
> Look in decoder dict for decoder function with given name ('set') and
> call it, passing arguments.
>
> Result would be {0, 1, 2}.
>
> Decoder for set:
>
> def decode_set(*args):
> return set(args)
>
> pyson.dumps({0, 1, 2}, decoders={'set': decode_set}) would return 'set(0, 1,
> 2)'.
>
> pyson.loads('set(0, 1, 2)', encoders={'set': encode_set}) would return {0,
> 1, 2}.
This seems very much overengineered. Keep it much more simple; adding
set notation is well and good, but keyword arguments aren't necessary
there, and I'm not seeing a tremendous use-case for them.
It's a pity Python has the collision of sets and dicts both using
braces. Pike went for two-character delimiters, which might be better
suited here; round brackets aren't used in JSON anywhere, so you can
afford to steal them:
{'this':'is', 'a':'dict'}
({'this','is','a','set'})
Empty sets would be an issue, though, as they'll be different in
Python and this format. But everything else would work fine. You have
a two-character delimiter in PyON, and superfluous parentheses around
set notation in Python.
(Sadly, this doesn't make it Pike-compatible, as Pike uses ()
for sets. But it wouldn't have been anyway.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thu, Sep 4, 2014 at 2:11 PM, Rustom Mody wrote: > Is there some PEP filed called "Abolish print in python 4" ? > I dont remember filing any such... You screamed "NO PRINT" at us in the voice of Edna Mode. (At least, that's how I imagined it being said. YMMV.) > Perhaps you should think of the relevance (rather than the > correctness) of your arguments Chris! Are you arguing > > 1. With me? > > If 1 then yeah I know when to use prints and when not This. Then why are you advocating their non-use to new programmers? Are you really saying print() is for experienced people only? Or, more generally, that it should be possible for new programmers to do absolutely all their coding at the REPL, never using any function with side effects or mutating any state? (I was going to say "or using any mutable objects", but since Python doesn't have tuple comprehensions, you'd have to use lists. But if you never change what a list contains, it comes to the same thing.) Because that is what I'm arguing against. New programmers and experienced programmers alike need their code to produce output, and return values are just one form of that. Excluding all other forms is unnecessary. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
1) There are, if you want to mess around with them, ways to make pickle
"smarter" about class stuff:
https://docs.python.org/2/library/pickle.html#pickling-and-unpickling-normal-class-instances
. I've never worked with any of this stuff (and people don't seem to like
pickle all that much), and I honestly think it might just be easier to
serialize class _data_ and then either create a factory that reads in e.g. a
json file and outputs class instances, or tweak __init__/__new__ to take the
data as an input.
2) re: "pyson," I'm pretty sure there are serialization formats that let you do
this kind of thing. I feel like I was _just_ reading about one somewhere, but
scrolling back through my browser history for the last 10 days or so turns up
nothing (it definitely included some kind of extension functionality,
though...). You could possibly approximate something like that with e.g. JSON
and some crafty en-/decoding, maybe like '"mySet: {"set": [0,1,2]}, "myTuple":
{"tuple": [0,1,2]}, "myObj": {"ClassName": {"foo": "bar", "baz": "quux"}}" + a
parser?
On Wednesday, September 3, 2014 10:19:07 PM UTC-4, Ned Batchelder wrote:
> On 9/3/14 6:30 PM, Josh English wrote:
>
> > On Wednesday, September 3, 2014 1:53:23 PM UTC-7, Ned Batchelder wrote:
>
> >
>
> >> Pickle (and it looks like jsonpickle) does not invoke the class'
>
> >> __init__ method when it reconstitutes objects. Your new __init__ is not
>
> >> being run, so new attributes it defines are not being created.
>
> >>
>
> >> This is one of the reasons that people avoid pickle: being completely
>
> >> implicit is very handy, but also fragile.
>
> >>
>
> >
>
> > I seem to remember having this exact same frustration when I used pickle
> > and shelve 15 years ago. I had hoped to have another way around this. I
> > spent over a decade trying to make an XML-based database work, in part
> > because of this limitation.
>
> >
>
> > Some days I get so frustrated I think the only data structure I should ever
> > use is a dictionary.
>
> >
>
> > I suppose to make this sort of thing work, I should look at creating custom
> > json encoders and decoders.
>
> >
>
>
>
> Typically, you need to decide explicitly on a serialized representation
>
> for your data. Even if it's JSON, you need to decide what that JSON
>
> looks like. Then you need to write code that converts the JSON-able
>
> data structure (dict of lists, whatever) into your object. Often a
>
> version number is a good idea so that you have some chance of using old
>
> data as your code changes.
>
>
>
> --
>
> Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 9:37:05 AM UTC+5:30, Ethan Furman wrote: > Ridiculous argument after ridiculous argument. Please do not waste our time > with nonsense. See my answer (3.) to Chris above. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 9:20:02 AM UTC+5:30, Chris Angelico wrote: > On Thu, Sep 4, 2014 at 1:22 PM, Rustom Mody wrote: > > | Effect-free programming > > | -- Function calls have no side effects, facilitating compositional > > reasoning > > | -- Variables are immutable, preventing unexpected changes to program data > > by other code > > | -- Data can be freely aliased or copied without introducing unintended > > effects from mutation > > So to answer your question: print statements are side-effecting and > > therefore obstruct > > compositional reasoning. > Yeah, fine. One small problem: Computers aren't built to do nothing. > "Effect-free programming" is utterly valueless and purposeless. To > make a program actually useful, you need to have some effect > somewhere. So where do you do that? Where do you permit a function > with side effects? > If you force *everything* to be in the return value, you lose any > possibility of partial results - for instance, if it takes two weeks > to render a ray-traced animation, you actually spend the entire two > weeks building up a single, gigantic return value, which some outside > system (which is presumably allowed to have side effects) then saves > somewhere. In the meantime, you have absolutely no idea how far it's > progressed - no information that it's completed frame 6 and is working > on frame 7, nothing. Because telling the user anything is a side > effect. > And if my function f calls show_status_to_user() which has side > effects, then f has side effects too, and you can no longer reason > purely about f. The impurity that makes for practicality (hey, isn't > there something in the Zen of Python about that?) pollutes upwards > until all you'll have will be pockets of pure functional code that > execute quickly enough to not need any intermediate output. That > doesn't equate to "abolish print", Is there some PEP filed called "Abolish print in python 4" ? I dont remember filing any such... Perhaps you should think of the relevance (rather than the correctness) of your arguments Chris! Are you arguing 1. With me? 2. With the OP? 3. With ACM/IEEE? If 1 then yeah I know when to use prints and when not If 2, are examples like ray-tracing animation remotely relevant (at this stage)? If 3 Sure! Take it up with ACM&IEEE if you feel something in their recommended curriculum is "valueless¹ and purposeless" > that just means that you separate > the guts from the UI - which is good advice for any system, no matter > what its structure. Yes thats the whole point -- computers do computing. IO should be conceptualized separately. -- ¹ Strange choice of word considering that one principal agenda of functional programming is to replace state-change thinking with value-oriented thinking -- https://mail.python.org/mailman/listinfo/python-list
Re: Best way to filter parts of a email.message.Message
On Thu, Sep 4, 2014 at 1:52 PM, Cameron Simpson wrote: > On 03Sep2014 20:59, Tim Chase wrote: >> >> - mime-parts can be nested, so I need to recursively handle them > > > Just to this. IIRC, the MIME part delimiter is supposed to be absolute. That > is, it will not occur in the nested subparts, if any. I think the point here is that the validity check of a mime-part may involve checking sub-parts - eg the message is a mailing list digest (with one part per actual message), and some of those have attachments, which are to be stripped off if over 1MB. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 09/03/2014 08:22 PM, Rustom Mody wrote: On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote: On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: NO PRINT Yes, or the OP could work with actual saved .py files and the reliability that comes from predictable execution environments... and use print. Why are you so dead against print? Here is the most recent (2013) ACM/IEEE CS curriculum: www.acm.org/education/CS2013-final-report.pdf It is divided into tiers with core-tier1 being the bare minimum that all CS graduate need to know. One of (the many!) things there is this (pg 158) | Functional Programming (3 Core-Tier1 hours) | Effect-free programming | -- Function calls have no side effects, facilitating compositional reasoning Lots of Python functions have side effects. | -- Variables are immutable, preventing unexpected changes to program data by other code Lots of Python core data types are mutable. | -- Data can be freely aliased or copied without introducing unintended effects from mutation Every mutable Python data type that is aliased can be affected by unintended mutational effects -- as well as intentional ones. So to answer your question: print statements are side-effecting and therefore obstruct compositional reasoning. Ridiculous argument after ridiculous argument. Please do not waste our time with nonsense. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Best way to filter parts of a email.message.Message
On 03Sep2014 20:59, Tim Chase wrote: - mime-parts can be nested, so I need to recursively handle them Just to this. IIRC, the MIME part delimiter is supposed to be absolute. That is, it will not occur in the nested subparts, if any. Of course that is no good to you working from outside via the email package, only if you're writing your own message dissector. Cheers, Cameron Simpson You can't wait for inspiration. You have to go after it with a club. - Jack London -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thu, Sep 4, 2014 at 1:22 PM, Rustom Mody wrote: > | Effect-free programming > | -- Function calls have no side effects, facilitating compositional reasoning > | -- Variables are immutable, preventing unexpected changes to program data > by other code > | -- Data can be freely aliased or copied without introducing unintended > effects from mutation > > So to answer your question: print statements are side-effecting and therefore > obstruct > compositional reasoning. Yeah, fine. One small problem: Computers aren't built to do nothing. "Effect-free programming" is utterly valueless and purposeless. To make a program actually useful, you need to have some effect somewhere. So where do you do that? Where do you permit a function with side effects? If you force *everything* to be in the return value, you lose any possibility of partial results - for instance, if it takes two weeks to render a ray-traced animation, you actually spend the entire two weeks building up a single, gigantic return value, which some outside system (which is presumably allowed to have side effects) then saves somewhere. In the meantime, you have absolutely no idea how far it's progressed - no information that it's completed frame 6 and is working on frame 7, nothing. Because telling the user anything is a side effect. And if my function f calls show_status_to_user() which has side effects, then f has side effects too, and you can no longer reason purely about f. The impurity that makes for practicality (hey, isn't there something in the Zen of Python about that?) pollutes upwards until all you'll have will be pockets of pure functional code that execute quickly enough to not need any intermediate output. That doesn't equate to "abolish print", that just means that you separate the guts from the UI - which is good advice for any system, no matter what its structure. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote: > On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: > NO PRINT > Yes, or the OP could work with actual saved .py files and the > reliability that comes from predictable execution environments... and > use print. Why are you so dead against print? Here is the most recent (2013) ACM/IEEE CS curriculum: www.acm.org/education/CS2013-final-report.pdf It is divided into tiers with core-tier1 being the bare minimum that all CS graduate need to know. One of (the many!) things there is this (pg 158) | Functional Programming (3 Core-Tier1 hours) | Effect-free programming | -- Function calls have no side effects, facilitating compositional reasoning | -- Variables are immutable, preventing unexpected changes to program data by other code | -- Data can be freely aliased or copied without introducing unintended effects from mutation So to answer your question: print statements are side-effecting and therefore obstruct compositional reasoning. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 7:56:31 AM UTC+5:30, Chris Angelico wrote: > On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody wrote: > > On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote: > >> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: > >> NO PRINT > >> Why are you so dead against print? > > Because it heralds a typical noob code-smell > > [especially when the OP admits that BASIC is his background] > And, of course, all those lovely Unix programs that produce output on > stdout, they're full of code smell too, right? I don't care what > someone's background is; console output is *not* code smell. Tell me the same after having taught a few thousand students If you are at the level of writing useful unix scripts, you are not going to be asking these questions. > Anyway, all you're doing is relying on the magic of interactive mode > to call repr() and print() for you. Yes its usually called DRY. That P in the REPL is put in a neat and nifty place. Why repeat? > >> Yes, or the OP could work with actual saved .py files and the > >> reliability that comes from predictable execution environments... and > >> use print. > > Dunno what you are talking about > > The interpreter-REPL is less reliable than a script? > When you start a script, you have a consistent environment - an empty > one. When you write a series of commands in the interactive > interpreter, the environment for each one depends on all the preceding > commands. So when you have a problem, you might have to copy and paste > the entire interpreter session, rather than just the one command. Agreed. Thats a downside. Very minor compared to the mess induced by unstructured print-filled noob code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thu, Sep 4, 2014 at 12:10 PM, Rustom Mody wrote: > On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote: >> On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: >> NO PRINT > > >> Why are you so dead against print? > > Because it heralds a typical noob code-smell > [especially when the OP admits that BASIC is his background] And, of course, all those lovely Unix programs that produce output on stdout, they're full of code smell too, right? I don't care what someone's background is; console output is *not* code smell. Anyway, all you're doing is relying on the magic of interactive mode to call repr() and print() for you. >> Yes, or the OP could work with actual saved .py files and the >> reliability that comes from predictable execution environments... and >> use print. > > Dunno what you are talking about > > The interpreter-REPL is less reliable than a script? When you start a script, you have a consistent environment - an empty one. When you write a series of commands in the interactive interpreter, the environment for each one depends on all the preceding commands. So when you have a problem, you might have to copy and paste the entire interpreter session, rather than just the one command. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
On Thursday, September 4, 2014 7:24:19 AM UTC+5:30, Steven D'Aprano wrote: > Marko Rauhamaa wrote: > > Steven D'Aprano: > >> Who uses + for disjunction (∨ OR) and concatenation for conjunction (∧ > >> AND)? That's crazy notation. > > That's the classic Boolean algebraic notation. > Says who? (Apart from you, obviously :-) Since when? I've never seen it in > *any* discussion of Boolean algebra. There are the mathematician/logicians who do boolean algebra (usually as part of lattice theory). They usually use ∧ ∨ ¬ The guys who (ab)use the add/multiply notations of school algebra are the electronics books — Karnaugh maps, minimization all that stuff. One or two pages of truth tables, some of this add/mul notation and then on its all the standard logic-circuit diagrams for combinational and sequential circuits. -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
On 9/3/14 6:30 PM, Josh English wrote: On Wednesday, September 3, 2014 1:53:23 PM UTC-7, Ned Batchelder wrote: Pickle (and it looks like jsonpickle) does not invoke the class' __init__ method when it reconstitutes objects. Your new __init__ is not being run, so new attributes it defines are not being created. This is one of the reasons that people avoid pickle: being completely implicit is very handy, but also fragile. I seem to remember having this exact same frustration when I used pickle and shelve 15 years ago. I had hoped to have another way around this. I spent over a decade trying to make an XML-based database work, in part because of this limitation. Some days I get so frustrated I think the only data structure I should ever use is a dictionary. I suppose to make this sort of thing work, I should look at creating custom json encoders and decoders. Typically, you need to decide explicitly on a serialized representation for your data. Even if it's JSON, you need to decide what that JSON looks like. Then you need to write code that converts the JSON-able data structure (dict of lists, whatever) into your object. Often a version number is a good idea so that you have some chance of using old data as your code changes. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
Seymore4Head wrote: > Ok, I understand now that x is actually the first item in the list. > What I want is a loop that goes from 1 to the total number of items in > the list steve. 99% of the time, you don't want that at all. Trust me, iterating over the values in the list is *nearly* always the right solution. But for those times you actually do want 1...N, use the range() function. Remember that in Python, ranges are "half open": the start value is *included*, but the end value is *excluded*. Also, the start value defaults to 0. So for example, if you wanted the numbers 1...5: range(5) --> range(0, 5) --> [0, 1, 2, 3, 4] range(1, 5+1) --> range(1, 6) --> [1, 2, 3, 4, 5] So to iterate over 1 to the number of items in list `steve`: for i in range(1, len(steve)+1): print(i) But if you are ever tempted to write something like this: for i in range(1, len(steve)+1): x = steve[i-i] # adjust the index from 1-based to 0-based print(i, x) we will take you out and slap you with a rather large hallibut https://www.youtube.com/watch?v=IhJQp-q1Y1s *wink* The right way to do that is: for i, x in enumerate(steve, 1): print(i, x) -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thursday, September 4, 2014 7:26:56 AM UTC+5:30, Chris Angelico wrote: > On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: > NO PRINT > Why are you so dead against print? Because it heralds a typical noob code-smell [especially when the OP admits that BASIC is his background] > Yes, or the OP could work with actual saved .py files and the > reliability that comes from predictable execution environments... and > use print. Dunno what you are talking about The interpreter-REPL is less reliable than a script? -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
On Thu, Sep 4, 2014 at 11:54 AM, Steven D'Aprano
wrote:
> although the
> analogy is terrible for ∨. 1+1 = 2, not 1.
I wouldn't say terrible. Unclear perhaps, but functional. Try this exercise:
false, true = 0, 1 # or use an old Python
if true + true:
print("true OR true is true")
As long as you accept that any non-zero value is true, and as long as
'and' and 'or' are the only operations you use (you can add 'not' as
long as it's defined the same way: "false if x else true"), addition
for or works fine.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Best way to filter parts of a email.message.Message
I'd like to do something like the following pseudocode
existing_message = mailbox[key] # an email.message.Message
new_message = email.message.Message()
for part in existing_message.walk():
if passes_test(part):
new_message.add(part) # need proper call here
else:
log("skipping %r" % part)
or alternatively something like this pseudocode inverse
new_message = copy.copy(existing_message)
for part in new_message.walk():
if fails_test(part):
new_message.magic_delete_part_method(part)
However, I want to make sure that just the selected mime-parts get
eliminated and that everything else (other mime-parts as well as
headers) gets copied over. Points giving me minor fits:
- mime-parts can be nested, so I need to recursively handle them
- making sure that if the source is/isn't multipart, that the
resulting new message is the same
- ensuring that headers get preserved (including the order)
Is there an obvious way to do this without rolling up my sleeves and
getting into the source for email.message and friends?
Thanks,
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Thu, Sep 4, 2014 at 11:48 AM, Rustom Mody wrote: NO PRINT Yes, or the OP could work with actual saved .py files and the reliability that comes from predictable execution environments... and use print. Why are you so dead against print? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Who uses + for disjunction (∨ OR) and concatenation for conjunction (∧
>> AND)? That's crazy notation.
>
> That's the classic Boolean algebraic notation.
Says who? (Apart from you, obviously :-) Since when? I've never seen it in
*any* discussion of Boolean algebra.
Since I answer my own question below (spoiler: George Boole), my questions
are rhetorical.
Mathworld says:
A Boolean algebra is a mathematical structure that is
similar to a Boolean ring, but that is defined using
the meet and join operators instead of the usual
addition and multiplication operators.
and lists the operators as:
^ (logical AND, or "wedge") and v (logical OR, or "vee")
http://mathworld.wolfram.com/BooleanAlgebra.html
Wikipedia lists the operators as
And (conjunction), denoted x∧y (sometimes x AND y or Kxy)
Or (disjunction), denoted x∨y (sometimes x OR y or Axy)
https://en.wikipedia.org/wiki/Boolean_algebra#Operations
So it seems that mathematicians have all but entirely abandoned the old
notation, although they are certainly aware that x∧y is analogous to xy
with both x, y elements of {0, 1}, and similarly for x∨y, although the
analogy is terrible for ∨. 1+1 = 2, not 1. If you perform the addition
modulo 2, then 1+1 = 0, which would make + analogous to XOR, not OR.
I had to go all the way back to George Boole's seminal work "An
Investigation Of The Laws Of Thought" in 1854 to find somebody using that
notation, and he had an excuse, namely he was inventing the subject.
http://gutenberg.org/ebooks/15114
Since Boole isn't with us any more, having died in 1864, my question still
stands: who would be so foolish to use this notation in the 21st century?
Answer: engineers.
http://www.allaboutcircuits.com/vol_4/chpt_7/2.html
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wednesday, September 3, 2014 11:41:27 PM UTC+5:30, Seymore4Head wrote: > import math > import random > import sys > b=[] > steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > for x in steve: > print (steve[x]) > Traceback (most recent call last): > print (steve[x]) > IndexError: list index out of range $ python Python 2.7.8 (default, Aug 23 2014, 21:00:50) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >>> steve [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >>> # You can see steve (strange name choice) without any printing >>> [x for x in steve] [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >>> # A bit long-winded but good to get used to; And NO PRINT >>> [(x,y) for (x,y) in zip(steve, range(100))] [(1, 0), (1, 1), (2, 2), (3, 3), (5, 4), (8, 5), (13, 6), (21, 7), (34, 8), (55, 9), (89, 10)] >>> # NO PRINT; but whats that 100 there? >>> [(x,y) for (x,y) in zip(steve, range(len(steve)))] [(1, 0), (1, 1), (2, 2), (3, 3), (5, 4), (8, 5), (13, 6), (21, 7), (34, 8), (55, 9), (89, 10)] >>> # NO PRINT; but sufficiently common that it needs a shortform >>> [(x,y) for (x,y) in enumerate(steve)] [(0, 1), (1, 1), (2, 2), (3, 3), (4, 5), (5, 8), (6, 13), (7, 21), (8, 34), (9, 55), (10, 89)] >>> # NO PRINT but why not just the simple >>> enumerate(steve) >>> # Hmm whats that?? >>> list(enumerate(steve)) [(0, 1), (1, 1), (2, 2), (3, 3), (4, 5), (5, 8), (6, 13), (7, 21), (8, 34), (9, 55), (10, 89)] >>> NO PRINT -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
On Thu, 04 Sep 2014 00:39:07 +0100, MRAB wrote: > It would add tuples, delimited by (...), which are not used otherwise > (no expressions): I guess <> and () are both unused as delims by json at present. I like the idea of other key types than string. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
On 2014-09-03 23:30, Josh English wrote:
On Wednesday, September 3, 2014 1:53:23 PM UTC-7, Ned Batchelder
wrote:
Pickle (and it looks like jsonpickle) does not invoke the class'
__init__ method when it reconstitutes objects. Your new __init__
is not being run, so new attributes it defines are not being
created.
This is one of the reasons that people avoid pickle: being
completely implicit is very handy, but also fragile.
I seem to remember having this exact same frustration when I used
pickle and shelve 15 years ago. I had hoped to have another way
around this. I spent over a decade trying to make an XML-based
database work, in part because of this limitation.
Some days I get so frustrated I think the only data structure I
should ever use is a dictionary.
I suppose to make this sort of thing work, I should look at creating
custom json encoders and decoders.
I occasionally think about a superset of JSON, called, say, "pyson" ...
ah, name already taken! :-(
In summary, it would be something like this:
JSON supports int, float, string, None (as 'null'), list and dict (the
key must be string).
It would add tuples, delimited by (...), which are not used otherwise
(no expressions):
() => ()
(0, ) => (0)
(0, 1) => (0, 1)
The key of a dict could also be int, float, or tuple.
It could support other classes, and could handle named arguments.
For example, sets:
To encode {0, 1, 2):
Look in encoder dict for encoder function with class's name ('set')
and call it, passing object.
Encoder returns positional and keyword arguments: [0, 1, 2] and {}.
Output name, followed by encoded arguments in parentheses.
Encoder for set:
def encode_set(obj):
return list(obj), {}
To decode 'set(0, 1, 2)':
Parse name: 'set'.
Parse contents of parentheses: [0, 1, 2] and {}.
Look in decoder dict for decoder function with given name ('set')
and call it, passing arguments.
Result would be {0, 1, 2}.
Decoder for set:
def decode_set(*args):
return set(args)
pyson.dumps({0, 1, 2}, decoders={'set': decode_set}) would return
'set(0, 1, 2)'.
pyson.loads('set(0, 1, 2)', encoders={'set': encode_set}) would return
{0, 1, 2}.
--
https://mail.python.org/mailman/listinfo/python-list
Latest Chess prog
Latest version of Chess test prog for anyone who might be interested.
It does not do en-passon or castling.
Best Regards
Chris
#!/opt/local/bin/pypy -u -tt
#!/opt/local/bin/pypy -u -tt -m cProfile
# -*- coding: utf-8 -*-
# Copyright (C) 2013-2014 Chris Hinsley, GPL V3 License
import sys, os, time
from operator import itemgetter
from array import array
MAX_PLY = 10
MAX_TIME_PER_MOVE = 10
PIECE_VALUE_FACTOR = 3
KING_VALUE, QUEEN_VALUE, ROOK_VALUE = 100, 9 * PIECE_VALUE_FACTOR,
5 * PIECE_VALUE_FACTOR
BISHOP_VALUE, KNIGHT_VALUE, PAWN_VALUE = 3 * PIECE_VALUE_FACTOR, 3 *
PIECE_VALUE_FACTOR, 1 * PIECE_VALUE_FACTOR
EMPTY, WHITE, BLACK = 0, 1, -1
NO_CAPTURE, MAY_CAPTURE, MUST_CAPTURE = 0, 1, 2
piece_type = {' ' : EMPTY, 'K' : BLACK, 'Q' : BLACK, 'R' : BLACK, 'B' :
BLACK, 'N' : BLACK, 'P' : BLACK, \
'k' : WHITE, 'q' : WHITE, 'r' : WHITE, 'b' : WHITE, 'n' : WHITE, 'p'
: WHITE}
def display_board(board):
print
print ' a b c d e f g h'
print '+---+---+---+---+---+---+---+---+'
for row in range(8):
for col in range(8):
print '| %c' % board[row * 8 + col],
print '|', 8 - row
print '+---+---+---+---+---+---+---+---+'
print
def piece_moves(board, index, vectors):
piece = board[index]
type = piece_type[piece]
promote = 'QRBN' if type == BLACK else 'qrbn'
cy, cx = divmod(index, 8)
for dx, dy, length, flag in vectors:
x, y = cx, cy
if length == 0:
if piece == 'P':
length = 2 if (y == 1) else 1
else:
length = 2 if (y == 6) else 1
while length > 0:
x += dx; y += dy; length -= 1
if (x < 0) or (x >=8) or (y < 0) or (y >= 8):
break
newindex = y * 8 + x
newpiece = board[newindex]
newtype = piece_type[newpiece]
if newtype == type:
break
if (flag == NO_CAPTURE) and (newtype != EMPTY):
break
if (flag == MUST_CAPTURE) and (newtype == EMPTY):
break
board[index] = ' '
if (y == 0 or y == 7) and piece in 'Pp':
for promote_piece in promote:
board[newindex] = promote_piece
yield board
else:
board[newindex] = piece
yield board
board[index], board[newindex] = piece, newpiece
if (flag == MAY_CAPTURE) and (newtype != EMPTY):
break
def piece_scans(board, index, vectors):
cy, cx = divmod(index, 8)
for dx, dy, length in vectors:
x, y = cx, cy
while length > 0:
x += dx; y += dy; length -= 1
if (0 <= x < 8) and (0 <= y < 8):
piece = board[y * 8 + x]
if piece != ' ':
yield piece
break
black_pawn_vectors = [(-1, 1, 1), (1, 1, 1)]
white_pawn_vectors = [(-1, -1, 1), (1, -1, 1)]
bishop_vectors = [(x, y, 7) for x, y in [(-1, -1), (1, 1), (-1, 1), (1, -1)]]
rook_vectors = [(x, y, 7) for x, y in [(0, -1), (-1, 0), (0, 1), (1, 0)]]
knight_vectors = [(x, y, 1) for x, y in [(-2, 1), (2, -1), (2, 1), (-2,
-1), (-1, -2), (-1, 2), (1, -2), (1, 2)]]
queen_vectors = bishop_vectors + rook_vectors
king_vectors = [(x, y, 1) for x, y, _ in queen_vectors]
black_pawn_moves = [(0, 1, 0, NO_CAPTURE), (-1, 1, 1, MUST_CAPTURE),
(1, 1, 1, MUST_CAPTURE)]
white_pawn_moves = [(x, -1, length, flag) for x, _, length, flag in
black_pawn_moves]
rook_moves = [(x, y, length, MAY_CAPTURE) for x, y, length in rook_vectors]
bishop_moves = [(x, y, length, MAY_CAPTURE) for x, y, length in bishop_vectors]
knight_moves = [(x, y, length, MAY_CAPTURE) for x, y, length in knight_vectors]
queen_moves = bishop_moves + rook_moves
king_moves = [(x, y, 1, flag) for x, y, _, flag in queen_moves]
moves = {'P' : black_pawn_moves, 'p' : white_pawn_moves, 'R' :
rook_moves, 'r' : rook_moves, \
'B' : bishop_moves, 'b' : bishop_moves, 'N' : knight_moves, 'n' :
knight_moves, \
'Q' : queen_moves, 'q' : queen_moves, 'K' : king_moves, 'k' :
king_moves}
white_scans = [('QB', bishop_vectors), ('QR', rook_vectors), ('N',
knight_vectors), ('K', king_vectors), ('P', white_pawn_vectors)]
black_scans = [('qb', bishop_vectors), ('qr', rook_vectors), ('n',
knight_vectors),
Re: Storing instances using jsonpickle
On Wednesday, September 3, 2014 1:53:23 PM UTC-7, Ned Batchelder wrote: > Pickle (and it looks like jsonpickle) does not invoke the class' > __init__ method when it reconstitutes objects. Your new __init__ is not > being run, so new attributes it defines are not being created. > > This is one of the reasons that people avoid pickle: being completely > implicit is very handy, but also fragile. > I seem to remember having this exact same frustration when I used pickle and shelve 15 years ago. I had hoped to have another way around this. I spent over a decade trying to make an XML-based database work, in part because of this limitation. Some days I get so frustrated I think the only data structure I should ever use is a dictionary. I suppose to make this sort of thing work, I should look at creating custom json encoders and decoders. Thanks, Josh -- https://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
On 09/03/2014 02:52 PM, jaron.br...@gmail.com wrote: Ethan, Steve, Tim, and others: I'm thinking of taking the program. How long, in hours, does it take to complete all four Python courses? That is an impossible question to answer accurately. I took the classes already having extensive knowledge of Python, which meant basically reading through the material, and doing the homework -- so probably an hour for reading, hour for the homework, or two hours per chapter, blah, blah, blah, roughly 30 hours for each class. So that's probably a mininum. Oh, and I also read pretty quickly. So if your reading speed is average or slow you should probably add another 30; if you're learning instead of reviewing add another 30; if applying new concepts to code does not come easy add another 30... So anywhere from 30 - 120 hours per class, or 120 - 480 for the course. I did say you wouldn't get an accurate answer, right? ;) I don't know who's teaching the classes now, but I was lucky enough to work with Kirby Urner and Steve Holden, and they were both great instructors. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
Ethan, Steve, Tim, and others: I'm thinking of taking the program. How long, in hours, does it take to complete all four Python courses? -Jaron Breen On Wednesday, December 15, 2010 12:54:27 PM UTC-5, Ethan Furman wrote: > So I just got an e-mail from O'Reilly and their School of Technology > about a Python Certification course... anybody have any experience with > this? > > It also says Steve Holden is involved -- is this True? (Steve?) > > ~Ethan~ > > PS > > Can you tell I've been programming? ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 03/09/2014 19:52, Seymore4Head wrote: I see that now. Thanks Maybe some comments in your code would help you? And also posting an on-topic title would help too. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head wrote: > import math import random import sys b=[] > steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > for x in steve: > print (steve[x]) > > Traceback (most recent call last): > File "C:\Functions\blank.py", line 7, in > print (steve[x]) > IndexError: list index out of range x is the value, not the index Try: steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] for x in steve: print (x) or if you want to use the index: for x in range(len(steve)): print (steve[x]) -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Storing instances using jsonpickle
On 9/3/14 4:32 PM, Josh English wrote: I am using jsonpickle to store instances of an object into separate data files. If I make any changes to the original class definition of the object, when I recreate my stored instances, they are recreated using the original class definition, so any new attributes, methods, or properties, are lost. I think this is happening because JSON is internalizing the class definition, ignoring the updates. Is this true? Is it possible to refresh JSON's knowledge of a class? Pickle (and it looks like jsonpickle) does not invoke the class' __init__ method when it reconstitutes objects. Your new __init__ is not being run, so new attributes it defines are not being created. This is one of the reasons that people avoid pickle: being completely implicit is very handy, but also fragile. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Storing instances using jsonpickle
I am using jsonpickle to store instances of an object into separate data files. If I make any changes to the original class definition of the object, when I recreate my stored instances, they are recreated using the original class definition, so any new attributes, methods, or properties, are lost. I think this is happening because JSON is internalizing the class definition, ignoring the updates. Is this true? Is it possible to refresh JSON's knowledge of a class? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 09/03/2014 11:41 AM, Seymore4Head wrote: On Wed, 03 Sep 2014 11:33:46 -0700, Ethan Furman wrote: Python will be incredibly hard if you don't read any of the docs or tutorials available. You can't accuse me of that. I have actually read quite a bit. I may not be picking it up, but I am trying. In that case I apologize for my remark. Keep trying -- once you get a handle on Python it is a very enjoyable language to use. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 3 Sep 2014 13:11:51 -0600, Ian Kelly wrote: >On Wed, Sep 3, 2014 at 12:49 PM, Seymore4Head > wrote: >> On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head >> wrote: >> >>>import math >>>import random >>>import sys >>>b=[] >>>steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >>>for x in steve: >>>print (steve[x]) >>> >>>Traceback (most recent call last): >>> File "C:\Functions\blank.py", line 7, in >>>print (steve[x]) >>>IndexError: list index out of range >> >> Ok, I understand now that x is actually the first item in the list. >> What I want is a loop that goes from 1 to the total number of items in >> the list steve. > >If you want the indexes also, you can do this: > >for i, x in enumerate(steve): >print(i, x) > >If you really want just the indexes and not the values, then you can do this: > >for i in range(len(steve)): >print(i) > >Most of the time though you will not need the indexes, and it will be >simpler just to work with the values by looping directly over the >list. I figured it out now. I was expecting x to be a number and not an item. I used for i in range(len(steve)): Thanks Printing x to see what it is instead of assuming what it is really helps. I am getting there. I just have to take smaller steps. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, Sep 3, 2014 at 12:49 PM, Seymore4Head wrote: > On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head > wrote: > >>import math >>import random >>import sys >>b=[] >>steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >>for x in steve: >>print (steve[x]) >> >>Traceback (most recent call last): >> File "C:\Functions\blank.py", line 7, in >>print (steve[x]) >>IndexError: list index out of range > > Ok, I understand now that x is actually the first item in the list. > What I want is a loop that goes from 1 to the total number of items in > the list steve. If you want the indexes also, you can do this: for i, x in enumerate(steve): print(i, x) If you really want just the indexes and not the values, then you can do this: for i in range(len(steve)): print(i) Most of the time though you will not need the indexes, and it will be simpler just to work with the values by looping directly over the list. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 03 Sep 2014 11:55:13 -0700 Ethan Furman wrote: > On 09/03/2014 11:49 AM, Seymore4Head wrote: > > On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head > > wrote: > > > >> import math > >> import random > >> import sys > >> b=[] > >> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > >> for x in steve: > >> print (steve[x]) > >> > >> Traceback (most recent call last): > >> File "C:\Functions\blank.py", line 7, in > >> print (steve[x]) > >> IndexError: list index out of range > > > > Ok, I understand now that x is actually the first item in the list. > > What I want is a loop that goes from 1 to the total number of items in > > the list steve. > > No, you don't understand yet. > > The /first/ time through the loop 'x' is the first item in the list. > > The /second/ time through the loop 'x' is the second item in the list. > > The /third/ time through the loop 'x' is the third item in the list. > > . . . > > Keep persisting! > > -- > ~Ethan~ Python 'for' is better read as 'for each'. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 3 Sep 2014 15:44:47 -0300, Juan Christian wrote: >I'm learning Python using this mailist, and the Tutor mailist, reading the >docs and watching this course, Python Fundamentals ( >http://www.pluralsight.com/training/Courses/TableOfContents/python-fundamentals >). > >Python is really easy and useful, OP don't blame the language because you >didn't understood it yet, just persist. > I don't think I have seen a link to that one yet. I have saved all the links I have seen posted here. I haven't tried all of them yet. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 09/03/2014 11:49 AM, Seymore4Head wrote: On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head wrote: import math import random import sys b=[] steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] for x in steve: print (steve[x]) Traceback (most recent call last): File "C:\Functions\blank.py", line 7, in print (steve[x]) IndexError: list index out of range Ok, I understand now that x is actually the first item in the list. What I want is a loop that goes from 1 to the total number of items in the list steve. No, you don't understand yet. The /first/ time through the loop 'x' is the first item in the list. The /second/ time through the loop 'x' is the second item in the list. The /third/ time through the loop 'x' is the third item in the list. . . . Keep persisting! -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 3 Sep 2014 13:28:39 -0500, Skip Montanaro wrote: >On Wed, Sep 3, 2014 at 1:24 PM, MRAB wrote: >> Iterating over a list yields its contents, not indexes. > >Unlike in JavaScript. Not sure where the OP is coming from, but that >"feature" of JavaScript threw me when I first encountered it. My guess >would be that his prior experience includes (at least) JS. > >Skip Actually it was BASIC some 30 years ago. I never got too good at BASIC and it doesn't look like I am going to get too good at Python either. :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 3 Sep 2014 18:17:27 + (UTC), John Gordon wrote: >In Seymore4Head > writes: > >> import math >> import random >> import sys > >Why are you importing these modules if they're not used? > >> b=[] > >Likewise b is not used. > >> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >> for x in steve: >> print (steve[x]) > >As you step through the loop, x becomes each successive item in the 'steve' >list. Therefore, you probably want to print just plain x, not steve[x]. > >> Traceback (most recent call last): >> File "C:\Functions\blank.py", line 7, in >> print (steve[x]) >> IndexError: list index out of range > >There are fewer than 13 items in steve, so when x reaches 13 this error >pops up. I see that now. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 3 Sep 2014 11:19:04 -0700, Rob Gaddi wrote: >On Wed, 03 Sep 2014 14:10:42 -0400 >Seymore4Head wrote: > >> import math >> import random >> import sys >> b=[] >> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >> for x in steve: >> print (steve[x]) >> >> Traceback (most recent call last): >> File "C:\Functions\blank.py", line 7, in >> print (steve[x]) >> IndexError: list index out of range > >You're failing to go through the basic tutorials, and blaming the >language when you don't understand things. > >'for x in steve' does not sweep x over the indices of steve. 'for x in >steve' sweeps x over the sequential _values_ in steve. This would have >been clear if you were to add a print(x) into the loop. Yes print(x) does make that clear Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 03 Sep 2014 14:10:42 -0400, Seymore4Head wrote: >import math >import random >import sys >b=[] >steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >for x in steve: >print (steve[x]) > >Traceback (most recent call last): > File "C:\Functions\blank.py", line 7, in >print (steve[x]) >IndexError: list index out of range Ok, I understand now that x is actually the first item in the list. What I want is a loop that goes from 1 to the total number of items in the list steve. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
I'm learning Python using this mailist, and the Tutor mailist, reading the docs and watching this course, Python Fundamentals ( http://www.pluralsight.com/training/Courses/TableOfContents/python-fundamentals ). Python is really easy and useful, OP don't blame the language because you didn't understood it yet, just persist. On Wed, Sep 3, 2014 at 3:33 PM, Ethan Furman wrote: > On 09/03/2014 11:10 AM, Seymore4Head wrote: > >> import math >> import random >> import sys >> b=[] >> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >> for x in steve: >> print (steve[x]) >> >> Traceback (most recent call last): >>File "C:\Functions\blank.py", line 7, in >> print (steve[x]) >> IndexError: list index out of range >> > > Python will be incredibly hard if you don't read any of the docs or > tutorials available. > > -- > ~Ethan~ > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 03 Sep 2014 11:33:46 -0700, Ethan Furman wrote: >On 09/03/2014 11:10 AM, Seymore4Head wrote: >> import math >> import random >> import sys >> b=[] >> steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] >> for x in steve: >> print (steve[x]) >> >> Traceback (most recent call last): >>File "C:\Functions\blank.py", line 7, in >> print (steve[x]) >> IndexError: list index out of range > >Python will be incredibly hard if you don't read any of the docs or tutorials >available. You can't accuse me of that. I have actually read quite a bit. I may not be picking it up, but I am trying. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 09/03/2014 11:10 AM, Seymore4Head wrote: import math import random import sys b=[] steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] for x in steve: print (steve[x]) Traceback (most recent call last): File "C:\Functions\blank.py", line 7, in print (steve[x]) IndexError: list index out of range Python will be incredibly hard if you don't read any of the docs or tutorials available. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, Sep 3, 2014 at 1:24 PM, MRAB wrote: > Iterating over a list yields its contents, not indexes. Unlike in JavaScript. Not sure where the OP is coming from, but that "feature" of JavaScript threw me when I first encountered it. My guess would be that his prior experience includes (at least) JS. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
In Seymore4Head writes: > import math > import random > import sys Why are you importing these modules if they're not used? > b=[] Likewise b is not used. > steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > for x in steve: > print (steve[x]) As you step through the loop, x becomes each successive item in the 'steve' list. Therefore, you probably want to print just plain x, not steve[x]. > Traceback (most recent call last): > File "C:\Functions\blank.py", line 7, in > print (steve[x]) > IndexError: list index out of range There are fewer than 13 items in steve, so when x reaches 13 this error pops up. -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On 2014-09-03 19:10, Seymore4Head wrote: import math import random import sys b=[] steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] for x in steve: print (steve[x]) Traceback (most recent call last): File "C:\Functions\blank.py", line 7, in print (steve[x]) IndexError: list index out of range Iterating over a list yields its contents, not indexes. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
On Wed, 03 Sep 2014 14:10:42 -0400 Seymore4Head wrote: > import math > import random > import sys > b=[] > steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > for x in steve: > print (steve[x]) > > Traceback (most recent call last): > File "C:\Functions\blank.py", line 7, in > print (steve[x]) > IndexError: list index out of range You're failing to go through the basic tutorials, and blaming the language when you don't understand things. 'for x in steve' does not sweep x over the indices of steve. 'for x in steve' sweeps x over the sequential _values_ in steve. This would have been clear if you were to add a print(x) into the loop. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python is going to be hard
print(x) :) 2014-09-03 20:10 GMT+02:00 Seymore4Head : > import math > import random > import sys > b=[] > steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] > for x in steve: > print (steve[x]) > > Traceback (most recent call last): > File "C:\Functions\blank.py", line 7, in > print (steve[x]) > IndexError: list index out of range > -- > https://mail.python.org/mailman/listinfo/python-list > -- Miguel García Lafuente - Rock Neurotiko Do it, the devil is in the details. The quieter you are, the more you are able to hear. Happy Coding. Code with Passion, Decode with Patience. If we make consistent effort, based on proper education, we can change the world. El contenido de este e-mail es privado, no se permite la revelacion del contenido de este e-mail a gente ajena a él. -- https://mail.python.org/mailman/listinfo/python-list
Python is going to be hard
import math import random import sys b=[] steve = [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89] for x in steve: print (steve[x]) Traceback (most recent call last): File "C:\Functions\blank.py", line 7, in print (steve[x]) IndexError: list index out of range -- https://mail.python.org/mailman/listinfo/python-list
[ANN] pathlib 1.0.1
Hello, I am announcing the release of pathlib 1.0.1. This version makes pathlib Python 2.6-compatible. Note that 2.6 compatibility may not have been as well tested as more recent Python versions (especially on non-Unix platforms). As a reminder, the standalone (PyPI) version of pathlib will not receive any new features or general improvements. New developments and regular bug fixes will happen mostly in the Python standard library, and be publicly available in official Python releases. See https://pypi.python.org/pypi/pathlib Overview pathlib offers a set of classes to handle filesystem paths. It offers the following advantages over using string objects: * No more cumbersome use of os and os.path functions. Everything can be done easily through operators, attribute accesses, and method calls. * Embodies the semantics of different path types. For example, comparing Windows paths ignores casing. * Well-defined semantics, eliminating any warts or ambiguities (forward vs. backward slashes, etc.). Requirements Python 3.2 or later is recommended, but pathlib is also usable with Python 2.6 and 2.7. Install --- In Python 3.4, pathlib is now part of the standard library. For Python 3.3 and earlier, ``easy_install pathlib`` or ``pip install pathlib`` should do the trick. Changelog for version 1.0.1 --- - Pull request #4: Python 2.6 compatibility by eevee. Regards Antoine. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to turn a string into a list of integers?
Peter Otten <__pete...@web.de> wrote:
> c...@isbd.net wrote:
>
> > I know I can get a list of the characters in a string by simply doing:-
> >
> > listOfCharacters = list("This is a string")
> >
> > ... but how do I get a list of integers?
> >
>
> >>> [ord(c) for c in "This is a string"]
> [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
>
> There are other ways, but you have to describe the use case and your Python
> version for us to recommend the most appropriate.
>
That looks OK to me. It's just for outputting a string to the block
write command in python-smbus which expects an integer array.
Thanks.
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
On Wednesday, September 3, 2014 12:00:10 PM UTC+3, Peter Otten wrote:
> dream4s...@gmail.com wrote:
>
>
>
> > calc_crc(b'\x00\x00\x34\x35\x38\x35')
>
>
>
> > unsigned char a[]={0x30,0x30,0x34,0x35,0x38,0x35};
>
>
>
> The first two bytes differ; you made an error on the input.
Dear Peter, my apologies it's my mistake. Thank you for help. Problem solved
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to turn a string into a list of integers?
El miércoles, 3 de septiembre de 2014 05:27:29 UTC-7, c...@isbd.net escribió:
> I know I can get a list of the characters in a string by simply doing:-
>
>
>
> listOfCharacters = list("This is a string")
>
>
>
> ... but how do I get a list of integers?
>
>
>
> --
>
> Chris Green
>
> ·
You Can Apply either, a map function or a list comprehension as follow:
Using Map:
>>> list(map(ord, listOfCharacters))
[84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
Using List Comprehension:
>>> [ord(n) for n in listOfCharacters]
[84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
Very Best Regards
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to turn a string into a list of integers?
c...@isbd.net wrote:
> I know I can get a list of the characters in a string by simply doing:-
>
> listOfCharacters = list("This is a string")
>
> ... but how do I get a list of integers?
>
>>> [ord(c) for c in "This is a string"]
[84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
There are other ways, but you have to describe the use case and your Python
version for us to recommend the most appropriate.
--
https://mail.python.org/mailman/listinfo/python-list
How to turn a string into a list of integers?
I know I can get a list of the characters in a string by simply doing:-
listOfCharacters = list("This is a string")
... but how do I get a list of integers?
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
On Wednesday, September 3, 2014 12:00:10 PM UTC+3, Peter Otten wrote:
> dream4s...@gmail.com wrote:
>
>
>
> > calc_crc(b'\x00\x00\x34\x35\x38\x35')
>
>
>
> > unsigned char a[]={0x30,0x30,0x34,0x35,0x38,0x35};
>
>
>
> The first two bytes differ; you made an error on the input.
Dear Peter, my apologies it's my mistake. Thank you for help. Problem solved.
--
https://mail.python.org/mailman/listinfo/python-list
AccInABox now has a wiki page (almost)
Hi all After putting my AccInABox package up on GitHub and letting a few people know about it, I received the following response - > > From: "Stéfan van der Walt" > > Hi Frank > > It would be great if the readme would list some features of the software > > so that one can decide whether it is suitable for one's own application. > Thanks for the interest, Stéfan. > I will spend some time over the weekend to draw something up, and I will > post it here. I am working on a 'feature list', but it is taking longer than expected, so here is a progress report and a preview. I decided to use the wiki page on my GitHub account. It took me a while to figure out how to use it effectively, but I think I have the hang of it now. I created a separate 'test' account to use while I am working on it, because each update to the wiki results in a 'revision', and I did not want to clutter up my main GitHub page with all my initial attempts. Once I am happy with it, I will upload the whole lot to my main page in one update. Here is a link to the test page - https://github.com/FrankMillman/test/wiki If anyone wants to have a look and offer feedback while I am working on it, that would be appreciated. Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
dream4s...@gmail.com wrote:
> calc_crc(b'\x00\x00\x34\x35\x38\x35')
> unsigned char a[]={0x30,0x30,0x34,0x35,0x38,0x35};
The first two bytes differ; you made an error on the input.
--
https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
On Wednesday, September 3, 2014 10:19:29 AM UTC+3, Peter Otten wrote:
> dream4s...@gmail.com wrote:
>
>
>
> > On Tuesday, September 2, 2014 9:24:54 PM UTC+3, Peter Otten wrote:
>
> >> dream4s...@gmail.com wrote:
>
> >>
>
> >>
>
> >>
>
> >> > I have trouble to implement crc algorithm in python 3.3
>
> >>
>
> >> >
>
> >>
>
> >> > c version work perfect. I try to use bytes, int and c_types without
>
> >> > any
>
> >>
>
> >> > success can some who help me:
>
> >>
>
> >>
>
> >>
>
> >> ctypes is for interfacing with C; don't use it in regular code.
>
> >>
>
> >>
>
> >>
>
> >> > c version:
>
> >>
>
> >> >
>
> >>
>
> >> > unsigned short calc_crc(const void *p_dat, int l_dat){
>
> >>
>
> >> > unsigned char *dat_ptr;
>
> >>
>
> >> > int loopc;
>
> >>
>
> >> > unsigned short crc_dat;
>
> >>
>
> >> > unsigned char c_work;
>
> >>
>
> >> >
>
> >>
>
> >> > dat_ptr = (unsigned char*)p_dat;
>
> >>
>
> >> > crc_dat = 0x;
>
> >>
>
> >> > for (; l_dat > 0; l_dat--)
>
> >>
>
> >> > {
>
> >>
>
> >> > c_work = *(dat_ptr++);
>
> >>
>
> >> > for (loopc = 0; loopc < 8; loopc++)
>
> >>
>
> >> > {
>
> >>
>
> >> > if unsigned char )(crc_dat & 0x0001)) ^
>
> >>
>
> >> > (c_work & 0x01)) == 0x01)
>
> >>
>
> >> > {
>
> >>
>
> >> > crc_dat >>=1 ;
>
> >>
>
> >> > crc_dat ^=0x8408;
>
> >>
>
> >> > } else {
>
> >>
>
> >> > crc_dat >>=1;
>
> >>
>
> >> >
>
> >>
>
> >> > }
>
> >>
>
> >> > c_work >>=1;
>
> >>
>
> >> > }
>
> >>
>
> >> > }
>
> >>
>
> >> > return(crc_dat);
>
> >>
>
> >> > }
>
> >>
>
> >>
>
> >>
>
> >> A near-literal translation would be:
>
> >>
>
> >>
>
> >>
>
> >> def calc_crc(data):
>
> >>
>
> >> crc = 0
>
> >>
>
> >> for work in data:
>
> >>
>
> >> for i in range(8):
>
> >>
>
> >> if (crc & 1) ^ (work & 1):
>
> >>
>
> >> crc >>= 1
>
> >>
>
> >> crc ^= 0x8408
>
> >>
>
> >> else:
>
> >>
>
> >> crc >>= 1
>
> >>
>
> >> work >>= 1
>
> >>
>
> >> return crc
>
> >>
>
> >>
>
> >>
>
> >> I don't see any operation where the "unboundedness" of Python's integer
>
> >> type
>
> >>
>
> >> could be a problem -- but no guarantees.
>
> >
>
> > this doesn't work
>
> >
>
> > calc_crc(b'\x00\x00\x34\x35\x38\x35')
>
> > rsult 0x9f41 , but c function gives us 0x8c40
>
>
>
> Are you sure? I get 0x9f41 with the C version you posted:
>
>
>
> $ cat crc.c
>
> #include
>
>
>
> unsigned short calc_crc(const void *p_dat, int l_dat){
>
> unsigned char *dat_ptr;
>
> int loopc;
>
> unsigned short crc_dat;
>
> unsigned char c_work;
>
>
>
> dat_ptr = (unsigned char*)p_dat;
>
> crc_dat = 0x;
>
> for (; l_dat > 0; l_dat--)
>
> {
>
> c_work = *(dat_ptr++);
>
> for (loopc = 0; loopc < 8; loopc++)
>
> {
>
> if unsigned char )(crc_dat & 0x0001)) ^ (c_work
>
> & 0x01)) == 0x01)
>
> {
>
> crc_dat >>=1 ;
>
> crc_dat ^=0x8408;
>
> } else {
>
> crc_dat >>=1;
>
>
>
> }
>
> c_work >>=1;
>
> }
>
> }
>
> return(crc_dat);
>
> }
>
>
>
> main()
>
> {
>
> unsigned char data[] = "\x00\x00\x34\x35\x38\x35";
>
> unsigned short crc = calc_crc(data, 6);
>
> printf("%x\n", crc);
>
> }
>
> $ gcc crc.c
>
> $ ./a.out
>
> 9f41
int main(int argc, char const *argv[])
{
unsigned short rez;
unsigned char a[]={0x30,0x30,0x34,0x35,0x38,0x35};
unsigned short val;
rez=calc_crc(a,(int)sizeof(a));
printf("%#hx\n",rez );
return 0;
}
o$ gcc main.c
o$ ./a.out
0x8c40
--
https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
On Wednesday, September 3, 2014 10:19:29 AM UTC+3, Peter Otten wrote:
> dream4s...@gmail.com wrote:
>
>
>
> > On Tuesday, September 2, 2014 9:24:54 PM UTC+3, Peter Otten wrote:
>
> >> dream4s...@gmail.com wrote:
>
> >>
>
> >>
>
> >>
>
> >> > I have trouble to implement crc algorithm in python 3.3
>
> >>
>
> >> >
>
> >>
>
> >> > c version work perfect. I try to use bytes, int and c_types without
>
> >> > any
>
> >>
>
> >> > success can some who help me:
>
> >>
>
> >>
>
> >>
>
> >> ctypes is for interfacing with C; don't use it in regular code.
>
> >>
>
> >>
>
> >>
>
> >> > c version:
>
> >>
>
> >> >
>
> >>
>
> >> > unsigned short calc_crc(const void *p_dat, int l_dat){
>
> >>
>
> >> > unsigned char *dat_ptr;
>
> >>
>
> >> > int loopc;
>
> >>
>
> >> > unsigned short crc_dat;
>
> >>
>
> >> > unsigned char c_work;
>
> >>
>
> >> >
>
> >>
>
> >> > dat_ptr = (unsigned char*)p_dat;
>
> >>
>
> >> > crc_dat = 0x;
>
> >>
>
> >> > for (; l_dat > 0; l_dat--)
>
> >>
>
> >> > {
>
> >>
>
> >> > c_work = *(dat_ptr++);
>
> >>
>
> >> > for (loopc = 0; loopc < 8; loopc++)
>
> >>
>
> >> > {
>
> >>
>
> >> > if unsigned char )(crc_dat & 0x0001)) ^
>
> >>
>
> >> > (c_work & 0x01)) == 0x01)
>
> >>
>
> >> > {
>
> >>
>
> >> > crc_dat >>=1 ;
>
> >>
>
> >> > crc_dat ^=0x8408;
>
> >>
>
> >> > } else {
>
> >>
>
> >> > crc_dat >>=1;
>
> >>
>
> >> >
>
> >>
>
> >> > }
>
> >>
>
> >> > c_work >>=1;
>
> >>
>
> >> > }
>
> >>
>
> >> > }
>
> >>
>
> >> > return(crc_dat);
>
> >>
>
> >> > }
>
> >>
>
> >>
>
> >>
>
> >> A near-literal translation would be:
>
> >>
>
> >>
>
> >>
>
> >> def calc_crc(data):
>
> >>
>
> >> crc = 0
>
> >>
>
> >> for work in data:
>
> >>
>
> >> for i in range(8):
>
> >>
>
> >> if (crc & 1) ^ (work & 1):
>
> >>
>
> >> crc >>= 1
>
> >>
>
> >> crc ^= 0x8408
>
> >>
>
> >> else:
>
> >>
>
> >> crc >>= 1
>
> >>
>
> >> work >>= 1
>
> >>
>
> >> return crc
>
> >>
>
> >>
>
> >>
>
> >> I don't see any operation where the "unboundedness" of Python's integer
>
> >> type
>
> >>
>
> >> could be a problem -- but no guarantees.
>
> >
>
> > this doesn't work
>
> >
>
> > calc_crc(b'\x00\x00\x34\x35\x38\x35')
>
> > rsult 0x9f41 , but c function gives us 0x8c40
>
>
>
> Are you sure? I get 0x9f41 with the C version you posted:
>
>
>
> $ cat crc.c
>
> #include
>
>
>
> unsigned short calc_crc(const void *p_dat, int l_dat){
>
> unsigned char *dat_ptr;
>
> int loopc;
>
> unsigned short crc_dat;
>
> unsigned char c_work;
>
>
>
> dat_ptr = (unsigned char*)p_dat;
>
> crc_dat = 0x;
>
> for (; l_dat > 0; l_dat--)
>
> {
>
> c_work = *(dat_ptr++);
>
> for (loopc = 0; loopc < 8; loopc++)
>
> {
>
> if unsigned char )(crc_dat & 0x0001)) ^ (c_work
>
> & 0x01)) == 0x01)
>
> {
>
> crc_dat >>=1 ;
>
> crc_dat ^=0x8408;
>
> } else {
>
> crc_dat >>=1;
>
>
>
> }
>
> c_work >>=1;
>
> }
>
> }
>
> return(crc_dat);
>
> }
>
>
>
> main()
>
> {
>
> unsigned char data[] = "\x00\x00\x34\x35\x38\x35";
>
> unsigned short crc = calc_crc(data, 6);
>
> printf("%x\n", crc);
>
> }
>
> $ gcc crc.c
>
> $ ./a.out
>
> 9f41
int main(int argc, char const *argv[])
{
unsigned short rez;
unsigned char a[]={0x30,0x30,0x34,0x35,0x38,0x35};
unsigned short val;
rez=calc_crc(a,(int)sizeof(a));
printf("%#hx\n",rez );
return 0;
}
--
https://mail.python.org/mailman/listinfo/python-list
Re: Editing text with an external editor in Python
On Tue, 02 Sep 2014 18:45:54 +1000, Chris Angelico wrote: > On Tue, Sep 2, 2014 at 6:35 PM, alister > wrote: >> if edlin is your only option then it would be better to spend you time >> writhing your own text editor! > > Heh! > > Considering how easy it is to deploy a multi-line edit widget in any GUI > toolkit, it shouldn't be too hard to write a GUI text editor. Now, > writing a *good* GUI text editor, that's a bit harder. And of course, > writing a text/console text editor, that's also less simple. But I put > it to you: How do you write your editor up to the point where you can > use it to write your editor? We have a bootstrapping problem! > > ChrisA fortunately i have a proper operating system now so I don't have have to use edlin. in the unlikely event that a reasonably featured editor is not available I can always use cat :-) -- Nothing is finished until the paperwork is done. -- https://mail.python.org/mailman/listinfo/python-list
Re: Raspberry pi, python and robotics
Rob Gaddi wrote: otherwise getting up and running will cost you a solid $1200 just in gear. While having fancy gear certainly helps, it's not *strictly* necessary. When I first started dabbling in electronics, the most sophisticated piece of equipment I had was an analog multimeter. It got me through a lot of projects, including a couple of homebrew computers. It's surprising how much you can deduce about what's happening in a digital circuit by watching a needle bouncing around! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
Steven D'Aprano : > Who uses + for disjunction (∨ OR) and concatenation for conjunction (∧ > AND)? That's crazy notation. That's the classic Boolean algebraic notation. In basic algebra, the two interesting operations are "addition" and "multiplication". Boolean math works like elementary arithmetics, with the exception that 1 + 1 = 1 I'm guessing the modern symbols ∨ and ∧ were derived from the set-theoretical analogues, ∪ and ∩, which were also formerly used for the same purpose. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
On 03/09/2014 07:19, dream4s...@gmail.com wrote: Would you please access this list via https://mail.python.org/mailman/listinfo/python-list or read and action this https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing double line spacing and single line paragraphs, thanks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: I have tried and errored a reasonable amount of times
On Tue, 02 Sep 2014 20:14:51 -0700, Rustom Mody wrote: > Dijkstra > used to point out > > A ∧ (B ∨ C) ≡ (A ∧ B) ∨ (A ∧ C) A ∨ (B ∧ C) ≡ (A ∨ B) ∧ (A ∨ C) look > normal enough in this form > > Put then into the way engineers do it and they become A(B + C) = AB + AC > A + BC = (A+B)(A+C) o_O Who uses + for disjunction (∨ OR) and concatenation for conjunction (∧ AND)? That's crazy notation. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: crc algorithm
dream4s...@gmail.com wrote:
> On Tuesday, September 2, 2014 9:24:54 PM UTC+3, Peter Otten wrote:
>> dream4s...@gmail.com wrote:
>>
>>
>>
>> > I have trouble to implement crc algorithm in python 3.3
>>
>> >
>>
>> > c version work perfect. I try to use bytes, int and c_types without
>> > any
>>
>> > success can some who help me:
>>
>>
>>
>> ctypes is for interfacing with C; don't use it in regular code.
>>
>>
>>
>> > c version:
>>
>> >
>>
>> > unsigned short calc_crc(const void *p_dat, int l_dat){
>>
>> > unsigned char *dat_ptr;
>>
>> > int loopc;
>>
>> > unsigned short crc_dat;
>>
>> > unsigned char c_work;
>>
>> >
>>
>> > dat_ptr = (unsigned char*)p_dat;
>>
>> > crc_dat = 0x;
>>
>> > for (; l_dat > 0; l_dat--)
>>
>> > {
>>
>> > c_work = *(dat_ptr++);
>>
>> > for (loopc = 0; loopc < 8; loopc++)
>>
>> > {
>>
>> > if unsigned char )(crc_dat & 0x0001)) ^
>>
>> > (c_work & 0x01)) == 0x01)
>>
>> > {
>>
>> > crc_dat >>=1 ;
>>
>> > crc_dat ^=0x8408;
>>
>> > } else {
>>
>> > crc_dat >>=1;
>>
>> >
>>
>> > }
>>
>> > c_work >>=1;
>>
>> > }
>>
>> > }
>>
>> > return(crc_dat);
>>
>> > }
>>
>>
>>
>> A near-literal translation would be:
>>
>>
>>
>> def calc_crc(data):
>>
>> crc = 0
>>
>> for work in data:
>>
>> for i in range(8):
>>
>> if (crc & 1) ^ (work & 1):
>>
>> crc >>= 1
>>
>> crc ^= 0x8408
>>
>> else:
>>
>> crc >>= 1
>>
>> work >>= 1
>>
>> return crc
>>
>>
>>
>> I don't see any operation where the "unboundedness" of Python's integer
>> type
>>
>> could be a problem -- but no guarantees.
>
> this doesn't work
>
> calc_crc(b'\x00\x00\x34\x35\x38\x35')
> rsult 0x9f41 , but c function gives us 0x8c40
Are you sure? I get 0x9f41 with the C version you posted:
$ cat crc.c
#include
unsigned short calc_crc(const void *p_dat, int l_dat){
unsigned char *dat_ptr;
int loopc;
unsigned short crc_dat;
unsigned char c_work;
dat_ptr = (unsigned char*)p_dat;
crc_dat = 0x;
for (; l_dat > 0; l_dat--)
{
c_work = *(dat_ptr++);
for (loopc = 0; loopc < 8; loopc++)
{
if unsigned char )(crc_dat & 0x0001)) ^ (c_work
& 0x01)) == 0x01)
{
crc_dat >>=1 ;
crc_dat ^=0x8408;
} else {
crc_dat >>=1;
}
c_work >>=1;
}
}
return(crc_dat);
}
main()
{
unsigned char data[] = "\x00\x00\x34\x35\x38\x35";
unsigned short crc = calc_crc(data, 6);
printf("%x\n", crc);
}
$ gcc crc.c
$ ./a.out
9f41
--
https://mail.python.org/mailman/listinfo/python-list
