Re: threading

[Rustom Mody]

On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote:
> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote:
> >  (1) oversimplification which makes it difficult to extend the design
> >  and handle all of the real-world contingencies
> 
> This I dont...

I meant "Dont understand"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Fri, 11 Apr 2014 13:59:00 +1000, Chris Angelico wrote:

> I have seen plenty of cultures where people are unaware of the value of
> interleaved/bottom posting, but so far, not one where anyone has
> actually required it. Not one. 

I've been in plenty of mailing list forums where interleaved posting was 
required, but there's only so many times you can tell people off for 
being rude before you start coming across as rude yourself.

It's one of those nasty aspects of human psychology: the guy who casually 
and without malice tosses litter out of his car window, spoiling things 
for everyone, is somehow considered less obnoxious than the person who 
tells him off. Except in Switzerland, where if you leave your rubbish bin 
out more than twenty minutes after its been emptied, the neighbours 
consider it perfectly acceptable to tell you off, never mind that you've 
been at work. And heaven help you if you take your discarded Christmas 
tree down to the street too early.


> "Norm" here just means "the thing people
> are too lazy to not do". That's not a reason for anyone else doing it.

I'm not sure what you are talking about. As far as I am concerned, the 
norm here absolutely is interleaved posting. Nearly all of the regular 
posters use it, have have done so for the decade or so I've been here. 
Interleaved posting requires more, not less, work -- that's one of the 
appeals of top-posting: it makes it easy to avoid editing your post for 
sense and readability, you can just bang on the keyboard and fire off 
whatever your first thoughts were, never mind actually answering the 
questions you were asked.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Chris Angelico]

On Fri, Apr 11, 2014 at 5:09 PM, Steven D'Aprano
 wrote:
> On Fri, 11 Apr 2014 13:59:00 +1000, Chris Angelico wrote:
>
>> I have seen plenty of cultures where people are unaware of the value of
>> interleaved/bottom posting, but so far, not one where anyone has
>> actually required it. Not one.
>
> I've been in plenty of mailing list forums where interleaved posting was
> required, but there's only so many times you can tell people off for
> being rude before you start coming across as rude yourself.

Oops, I worded that badly. What I meant was "not one where anyone has
actually required top-posting". There are places where bottom-posting
is expected/required, there are places where nobody cares enough to
complain, but I've yet to meet any where bottom posting is actually
forbidden.

>> "Norm" here just means "the thing people
>> are too lazy to not do". That's not a reason for anyone else doing it.
>
> I'm not sure what you are talking about. As far as I am concerned, the
> norm here absolutely is interleaved posting. Nearly all of the regular
> posters use it, have have done so for the decade or so I've been here.
> Interleaved posting requires more, not less, work -- that's one of the
> appeals of top-posting: it makes it easy to avoid editing your post for
> sense and readability, you can just bang on the keyboard and fire off
> whatever your first thoughts were, never mind actually answering the
> questions you were asked.

Right, and I'm glad that the norm here happens to be the better
option. But the reason for advocating it is not "everyone else does
it", but "it's the better way".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: gdb python print truncated string

[Wesley]

在 2014年4月8日星期二UTC+8上午10时21分24秒，Wesley写道：
> Hi all,
> 
>   I have a question regarding gdb python.
> 
> I use gdb7.7 and python2.7.6.
> 
> 
> 
> Here is snippet that py-print one variable:
> 
> (gdb) py-print self
> 
> local 'self' =  0x7f860614b220>, timer513645288=<_Timeout at remote 0xb42f760>, 
> timer1248840930=<_Timeout at remote 0x7f85f7f4c300>, 
> timer1678666863=<_Timeout at remote 0x7f85fec0ddf0>, timer888598936=<_Timeout 
> at remote 0x7f860579a300>, timer1566174556=<_Timeout at remote 0xe69a7d0>, 
> timer1307561941=<_Timeout at remote 0x7f85e41145a0>, 
> timer1010094072=<_Timeout at remote 0xb42af40>, to_device={u'sendno': 
> u'1252682169', u'msg_content': {u'message': {u'command': True}}, u'msg_type': 
> u'2'}, timer2050775853=<_Timeout at remote 0x7f8606ddcb50>, 
> timer1115907467=<_Timeout at remote 0x9c02140>, timer333587031=<_Timeout at 
> remote 0xbb25450>, timer71350378=<_Timeout at remote 0x7f85e5e38220>, 
> timer1044716881=<_Timeout at remote 0x7f86053094c0>, 
> timer2069059536=<_Timeout at remote 0x7f85f3d3b530>, 
> timer2139990080=<_Timeout at remote 0x8bd5370>, timer1121163931=<_Timeout at 
> remote 0x99e5370>, queue= at remote 0x7081600>, maxsize=0, all_ta...(truncated)
> 
> 
> 
> self is instance of Connection class.
> 
> So, actually, I wanna check self.status...but you can see the print is 
> truncated.
> 
> I tried py-print self.status but failed.
> 
> After a lot google work, somebody mention gdb 'set print elements 0/-1', but 
> still failed..
> 
> 
> 
> So, how to check self.status value?
> 
> 
> 
> Thanks.
> 
> Wesley

Does anyone know this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Ian Kelly  wrote:

> The only reliable way to prevent a customer from reverse-engineering
> your software is to not give them the software.  

Not really. You just need to make it so difficult that it is not worth the
effort. In that case they will go away and do something else instead. At
least if the threat is other companies out to make money. Dropbox is an
example.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Wesley  wrote:

>   Does python has any good obfuscate?
> 
> Currently our company wanna release one product developed by python to
> our customer. But dont's wanna others see the py code.
> 
> I googled for a while but mostly just say using pyc. Any better one?

It depends on the threat and how competent persons you want to protect your
code from. If this comes from your boss, chances are he does not know that
even x86 machine code can be decompiled. So as many has said, this is
mostly futile business. The only way to protect your code is never to ship
anything. 

Hacking the interpreter might be satisfactory to calm your boss:

- Run a script that strips comments and make variable names
incomprehensible
- Swap .pyc byte codes so they don't mean the same as in vanilla Python
- Make the compiler spit out scrambled bytes and make the .pyc loader
unencrypt

Any of these measures can be circumvented, though. But it is hardly easier
to read than compiled C++.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Joshua Landau  wrote:

> However, if this really is your major blocker to using Python, I
> suggest compiling with Cython.

Cython restains all the code as text, e.g. to readable generate exceptions.
Users can also still steal the extension modules and use them in their own
code. In general, Cython is not useful as an obfuscation tool.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[wxjmfauth]

Unicode!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Sturla Molden]

Steven D'Aprano  wrote:

>> I have an issue with the use of coroutines. I think they are to evil.
> 
> They are to evil ... as what? To evil as chalk is to cheese? Black is to 
> white? Bees are to honey? 

I think coroutines are one of those things that don't fit the human mind.

A class with a couple of queues for input and output is far easier to
comprehend.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Thu, 10 Apr 2014 21:37:22 -0700, Rustom Mody wrote:

> Right. Its true that when I was at a fairly large corporate, I was not
> told: "Please always top post!"

That's only because they are ignorant of the terminology of top- bottom- 
and interleaved posting. If they knew the term, they would say it.


> What I was very gently and super politely told was: "Please dont delete
> mail context"

And your answer was, "I'm not. All the context required to establish 
meaning is there." Correct?

Or perhaps you said, "When you send a letter via paper mail, replying to 
someone's enquiry, do you photocopy their letter and staple it to the 
back of your response? And when they reply, to they photocopy YOUR 
response, *including the photocopy of their letter*, and sent it back? Of 
course you don't. That would be *idiotic*. It's no less idiotic when the 
effort of photocopying the letter is reduced to hitting Reply in Outlook."

Standard business handling of email truly is foolish. People only get 
away with it because, for the most part, *they stop reading* as soon as 
they hit the end of the top-posted reply (and their reading comprehension 
of that is generally lousy, but that's another story) and don't even 
notice that there are 15 pages of quoted-quoted-quoted-quoted-quoted-
quoted copies of their own words attached, complete with 10 copies of 
their (legally meaningless) disclaimer.

All this redundancy does nothing for improved communication, and it has 
real costs: emails are bigger than they need be, searching archives for 
information is harder, and if you're ever involved in a legal dispute, 
instead of paying your lawyer to review six pages of correspondence 
you're paying her to review sixty pages with the same semantic content. 
Top-posting is a classic example of the victory of short term gain 
(immediately save two seconds and a microscopic amount of effort when 
replying to an email) versus long term cost.


> Now when a mail goes round between 5 persons and what is addressed at
> one point is not the immediate previous mail, bottom-posting without
> pruning is as meaningless as top posting.

Ha. In my experience, anything not addressed immediately in corporate 
email is *never addressed again*, not until the original poster starts a 
new email to try to get an answer.


> As in religion or any cultural matter, its fine to stand up for and even
> vociferously uphold one's 'own' whatever that may be.
> 
> What is unhelpful is
> - to suggest that my norms are universal norms. IOW there is a
> fundamental difference between natural and human-made laws
> - to lose track of statistics, in this case the population-densities of
> USENET vs other internet-kiddie cultures


I don't know that there is anyone here that thinks interleaved posting is 
the norm among the majority of email users. Nor is anyone saying that 
Usenet posters make up a majority of internet users. What we are saying 
is that *interleaved posting is objectively better* for most forms of 
email or news communication (although it is not a panacea), and 
especially for *technical discussions* like those that occur here.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Chris Angelico]

On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden  wrote:
> The only way to protect your code is never to ship anything.

It's worth noting, as an aside, that this does NOT mean you don't
produce or sell anything. You can keep your code secure by running it
on a server and permitting users to access it; that's perfectly safe.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Thu, 10 Apr 2014 23:39:24 -0600, Ian Kelly wrote:

> On Thu, Apr 10, 2014 at 11:11 PM, Chris Angelico 
> wrote:
[...]
>> Then you were told that by someone who does not understand email.
>> That's equivalent to being told "Don't ever delete any of your code,
>> just comment it out". I don't care who's saying that, it's bad advice.
> 
> That depends on what the mail is being used for.  For instance there's a
> difference between mail-as-dialogue and mail-as-business-process. In the
> former it is normal, even polite, to prune as the topic evolves and past
> quotations become less relevant.

Exactly.


> In the latter it seems more common for
> the entire thread to be preserved as a sort of "chain of custody" --

I think this is a rationalisation after the fact, and does not reflect 
actual practice with email.


> this way the next person who needs to see the email thread has full
> context as to what needs to happen and where the request is coming from.

I think this is wrong. First of all, quite often the newcomer doesn't 
need or want to see the full *history*. They need to know the *current* 
situation -- customer X wants to order 50,000 widgets *now*, the fact 
that seven emails ago they were asking for a quote on 20,000 gadgets is 
irrelevant.

Secondly, as soon as you have three or more people actively taking part 
is a conversation by email, no single email contains the entire history. 
So you still have to point the newcomer at some archive where they can 
see all the emails.

Thirdly, even when it is useful to read the entire history, it is far 
more understandable and efficient to read it in the order that it was 
written, not in reverse order.

I think that the habit of including the entire email history is just a 
side-effect of the typical corporate laziness and selfishness 
masquerading as "efficiency". Rather than take five minutes of my time to 
bring somebody up to speed with a summary telling them exactly what they 
need to know and nothing but what they need to know, I spend two seconds 
dumping the entire file in their lap. That's much more efficient! Except 
that the newcomer then has to spend twenty minutes or an hour and may end 
up misunderstanding the situation. But that's *his* fault, not mine -- my 
butt is covered.

(You'll notice that nobody ever does this kind of info-dump on high-
ranking executives. *Then* they take the time to write an executive 
summary.)

It is, in a way, the corporate equivalent of "RTFM", only enshrined as 
normal practice rather than seen as a deliberate put-down of somebody who 
hasn't done their homework. And because it's normal practice, even those 
who know better end up going along with the flow, because its easier than 
explaining to their supervisor why their emails are so confusing. And 
thus the world is made a slightly darker place.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Chris Angelico]

On Fri, Apr 11, 2014 at 8:07 PM, Steven D'Aprano
 wrote:
> It is, in a way, the corporate equivalent of "RTFM", only enshrined as
> normal practice rather than seen as a deliberate put-down of somebody who
> hasn't done their homework. And because it's normal practice, even those
> who know better end up going along with the flow, because its easier than
> explaining to their supervisor why their emails are so confusing. And
> thus the world is made a slightly darker place.

It's even worse. If someone comes to you saying "So what's this
Heartbleed thing?", RTFM would be providing a link to
https://en.wikipedia.org/wiki/Heartbleed but the default corporate
practice is linking to
https://en.wikipedia.org/w/index.php?title=Heartbleed&action=history
and expecting the someone to read it all. But yes.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Ian Kelly]

On Fri, Apr 11, 2014 at 3:17 AM, Sturla Molden  wrote:
> Ian Kelly  wrote:
>
>> The only reliable way to prevent a customer from reverse-engineering
>> your software is to not give them the software.
>
> Not really...

On Fri, Apr 11, 2014 at 3:17 AM, Sturla Molden  wrote:
> It depends on the threat and how competent persons you want to protect your
> code from. If this comes from your boss, chances are he does not know that
> even x86 machine code can be decompiled. So as many has said, this is
> mostly futile business. The only way to protect your code is never to ship
> anything.

How is that last statement different from the one I made above, that
you disagreed with?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[alister]

On Fri, 11 Apr 2014 06:34:46 +0100, Paul Rudin wrote:
> 
> It's not necessarily a bad idea to retain context in corporate emails.
> Messages tend to get forwarded to people other than the original
> recipient(s), and the context can be very helpful.
> 
Right up to the point when someone forwards on an internal email chain to 
an external customer without bothering to prune out the bit where someone 
(usually an engineer like myself) has stated (bluntly) that what the 
salesman is proposing will never work*.

the longer the chain the more likely it is for something like that to be 
missed by the sender who wont have bothered to read everything (for some 
reason the recipient always finds the embarrassing statements).
 
*Or some other commercially sensitive & even more damming piece of 
information.


-- 
Having children is like having a bowling alley installed in your brain.
-- Martin Mull
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Chris Angelico]

On Fri, Apr 11, 2014 at 8:46 PM, alister
 wrote:
> Right up to the point when someone forwards on an internal email chain to
> an external customer without bothering to prune out the bit where someone
> (usually an engineer like myself) has stated (bluntly) that what the
> salesman is proposing will never work*.
>
> the longer the chain the more likely it is for something like that to be
> missed by the sender who wont have bothered to read everything (for some
> reason the recipient always finds the embarrassing statements).
>
> *Or some other commercially sensitive & even more damming piece of
> information.

According to Snopes, that has happened in an email variant of the old
"send this guy the standard cockroach letter" story (which is itself
plausible and not provably false):

http://www.snopes.com/business/consumer/bedbug.asp

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Thu, 10 Apr 2014 22:42:14 -0700, Rustom Mody wrote:

> In middle-eastern society women are expected to dress heavier than in
> the West. A few years ago a girl went to school in France with a scarf
> and she was penalized.

Citation please. I think this is bogus, although given how obnoxious some 
schools can be I'm not quite prepared to rule it out altogether. I think 
it's far more likely that she was only penalized for wearing full head-
covering (not just a scarf) after being warned that it was not part of 
the school uniform and therefore not appropriate.


[...]
> People whose familiarity with religion is limited to the Judeo-Christian
> tradition are inclined to the view (usually implicit) that "being
> religious" == "belief in God"
> However there are religions where belief in God is irreligious --
> Jainism 

I think that it will come as rather a surprise to Jains to be told that 
they don't believe in god. In fact, they believe in a multitude of gods 
(not surprising, as Jainism is derived from Hinduism) and believe that 
every soul has the potential to become a god. 


> And others where it is is irrelevant -- Tao, Shinto. [There is
> the story of a westerner who wen to a shinto temple and said: All this
> (rites) is fine and beautiful but what's your *philosophy* To which he
> was told: "Philosophy? We have no philosophy! We dance!"]

A nice story, but the name "Shinto" even means "The Way Of The Gods", so 
claiming that Shinto is not about gods is rubbish.

It might be true that there is a particular Shinto temple where they have 
no religious beliefs and just dance for the love of it, but that's hardly 
the case for *all* Shinto. That would be a bit like claiming that 
Christians don't believe in god because some Unitarians are atheists. 
Shinto has no founder, no overarching doctrine, and no official religious 
texts, so you are more likely to find widely-varying religiosity than 
among Christian churches, but to generalise to all Shinto is misleading.

Similarly for Taoism (Daoism). The Tao itself is not a religious concept, 
it is more of a mystical/philosophical concept than a theistic one, but 
Taoism is a religion with many gods. It seems to me that your statement 
that belief in gods is irrelevant to Taoism is making the same category 
mistake as it would be to say that belief in Jesus is irrelevant to 
Christianity because Faith is not a religious concept[1].


>> That's equivalent to being told "Don't ever delete any of your code,
>> just comment it out". I don't care who's saying that, it's bad advice.
> 
> The correct analogy: "Dont ever delete content from the repository"

No -- the repository is the email archive. (Your inbox, perhaps.) You 
don't keep a copy of the entire repo in every source file.



[1] Or at least, not necessarily a religious concept.

-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Thu, 10 Apr 2014 22:54:23 -0700, Rustom Mody wrote:

> What I am pointing out is that if one gets so besotted with irritation
> as to lose coherence, its unlikely that any useful communication will
> ensue.

This, a million times.

If all we do is be curmudgeons who complain about GG's poor posting 
styles, we will end up making this forum irrelevant.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Steven D'Aprano]

On Fri, 11 Apr 2014 04:22:49 -0600, Ian Kelly wrote:

> On Fri, Apr 11, 2014 at 3:17 AM, Sturla Molden 
> wrote:
>> Ian Kelly  wrote:
>>
>>> The only reliable way to prevent a customer from reverse-engineering
>>> your software is to not give them the software.
>>
>> Not really...
> 
> On Fri, Apr 11, 2014 at 3:17 AM, Sturla Molden 
> wrote:
>> It depends on the threat and how competent persons you want to protect
>> your code from. If this comes from your boss, chances are he does not
>> know that even x86 machine code can be decompiled. So as many has said,
>> this is mostly futile business. The only way to protect your code is
>> never to ship anything.
> 
> How is that last statement different from the one I made above, that you
> disagreed with?


Isn't it obvious? When *you* say something, you're making a knee-jerk 
reaction without considering all the circumstances, so even if you're 
right you're right for the wrong reasons and hence wrong. But when *I* 
say the same thing, I've made a deep and careful consideration of all the 
nuances and therefore am right for the right reasons and hence right.

:-)



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Paul Rudin]

Steven D'Aprano  writes:

> On Thu, 10 Apr 2014 22:42:14 -0700, Rustom Mody wrote:
>
>> In middle-eastern society women are expected to dress heavier than in
>> the West. A few years ago a girl went to school in France with a scarf
>> and she was penalized.
>
> Citation please. I think this is bogus...

This is not bogus. France has quite a strong tradition of keeping the
education system secular and has passed a law regarding the wearing of
"ostentatious" religious symbols in public schools, which also affects
things like the wearing of crosses.

Wikipedia has plenty on this...



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[alister]

On Fri, 11 Apr 2014 21:01:46 +1000, Chris Angelico wrote:

> On Fri, Apr 11, 2014 at 8:46 PM, alister
>  wrote:
>> Right up to the point when someone forwards on an internal email chain
>> to an external customer without bothering to prune out the bit where
>> someone (usually an engineer like myself) has stated (bluntly) that
>> what the salesman is proposing will never work*.
>>
>> the longer the chain the more likely it is for something like that to
>> be missed by the sender who wont have bothered to read everything (for
>> some reason the recipient always finds the embarrassing statements).
>>
>> *Or some other commercially sensitive & even more damming piece of
>> information.
> 
> According to Snopes, that has happened in an email variant of the old
> "send this guy the standard cockroach letter" story (which is itself
> plausible and not provably false):
> 
> http://www.snopes.com/business/consumer/bedbug.asp
> 
> ChrisA

forget Snopes I have personally been hauled into a managers office 
because something i put in an email to another member of staff was then 
forwarded to the customer.

Fortunately my defence of "internal emails should not be being forwarded 
to customers without being sanitised" was accepted (& the other member of 
staff educated)



-- 
Code like that would not pass through anybody's yuck-o-meter.

- Linus Torvalds about design on linux-kernel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Fri, 11 Apr 2014 12:46:05 +0100, Paul Rudin wrote:

> Steven D'Aprano  writes:
> 
>> On Thu, 10 Apr 2014 22:42:14 -0700, Rustom Mody wrote:
>>
>>> In middle-eastern society women are expected to dress heavier than in
>>> the West. A few years ago a girl went to school in France with a scarf
>>> and she was penalized.
>>
>> Citation please. I think this is bogus...
> 
> This is not bogus. France has quite a strong tradition of keeping the
> education system secular and has passed a law regarding the wearing of
> "ostentatious" religious symbols in public schools, which also affects
> things like the wearing of crosses.
> 
> Wikipedia has plenty on this...
> 
> 


Which does not differ that much from the rest of my post, which you 
deleted. It wasn't just a scarf, it was a religious head-covering, the 
hijab, and despite the original context which suggests that the poor girl 
happened to turn up to school one day with a scarf and was penalized just 
for bringing it to school, the three girls were asked to remove their 
hijabs, and were only penalized when they refused to obey school rules.

I don't know where I stand on the hijab in general, but in this specific 
case, I stand by my skepticism about Rustom's description.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[cl]

Chris Angelico  wrote:
> On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden  
> wrote:
> > The only way to protect your code is never to ship anything.
> 
> It's worth noting, as an aside, that this does NOT mean you don't
> produce or sell anything. You can keep your code secure by running it
> on a server and permitting users to access it; that's perfectly safe.
> 
Perfectly?  :-)

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Tim Chase]

On 2014-04-11 11:34, Steven D'Aprano wrote:
> >> That's equivalent to being told "Don't ever delete any of your
> >> code, just comment it out". I don't care who's saying that, it's
> >> bad advice.  
> > 
> > The correct analogy: "Dont ever delete content from the
> > repository"  
> 
> No -- the repository is the email archive. (Your inbox, perhaps.)
> You don't keep a copy of the entire repo in every source file.

Clearly you've not seen some of the corporate code-bases I've had to
touch. «shudder»  I still have nightmares about vast swaths of code
commented out or "#ifdef 0"ed out.

Then again, since they used Visual Source Safe, it might have been
the smarter/safer option ;-)

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Roy Smith]

In article <53477f29$0$29993$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

> I think coroutines are awesome, but like all advanced concepts, sometimes 
> they can be abused, and sometimes they are hard to understand not because 
> they are hard to understand in and of themselves, but because they are 
> being used to do something inherently complicated.

Advanced, perhaps.  But certainly not new.  The first "real" computer I 
worked on (a pdp-11/45) had a hardware instruction which swapped 
execution contexts.  The documentation described it as being designed to 
support coroutines.  That's a machine which was designed in the early 
1970s.

Heh, Wikipedia's [[Coroutine]] article says, "The term coroutine was 
coined by Melvin Conway in a 1963 paper".

At a high level, threads and coroutines are really very similar.  They 
are both independent execution paths in the same process.  I guess the 
only real difference between them is that thread switching is mediated 
by the operating system, so it can happen anywhere (i.e. at any 
instruction boundary).  Coroutines scheduling is handled in user code, 
so you have a lot more control over when context switches happen.  This 
makes it a lot easier to manage operations which must occur atomically.

They both operate in the same process memory space, so have the 
potential to stomp on each others data structures.  They also both have 
the property that there is flow of control happening which is not 
apparent from a top-down reading of the code (exceptions, to a certain 
extent, have this same problem).  This is fundamentally what makes them 
difficult to understand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Ian Kelly  wrote:

> How is that last statement different from the one I made above, that
> you disagreed with?

Who says I disagreed? 

But to answer you question, it depends on the level of safety you need:
Total secrecy or just enough protection to make it not worthwhile to access
the code?


Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interleaved vs. top-posting

[Tim Chase]

On 2014-04-11 13:59, Chris Angelico wrote:
> I have seen plenty of cultures where people are unaware of the value
> of interleaved/bottom posting, but so far, not one where anyone has
> actually required it. Not one.

The only time I've seen top-posting required (though there was
nothing about trimming/dropping the content from the bottom) was on
some lists for blind users where they wanted the new content at the
top of the email rather than having to wade through lots of content
they'd heard previously.  The actual context was usually either given
by in-sentence referencing to the topic, or the subject-heading
(blind folks seem to have an incredible memory for things sighted
folks are usually too lazy to remember).

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Chris Angelico]

On Fri, Apr 11, 2014 at 10:32 PM,   wrote:
> Chris Angelico  wrote:
>> On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden  
>> wrote:
>> > The only way to protect your code is never to ship anything.
>>
>> It's worth noting, as an aside, that this does NOT mean you don't
>> produce or sell anything. You can keep your code secure by running it
>> on a server and permitting users to access it; that's perfectly safe.
>>
> Perfectly?  :-)

Heh. Well, as perfectly as anything ever is. All they can do is try to
find exploits (hi, Heartbleed!) and get at some of the code. It's not
like "hey look, here it is, I can just run it".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Mark Lawrence]

On 11/04/2014 10:25, wxjmfa...@gmail.com wrote:


Unicode!



Works perfectly in Python 3.3+ thanks to the excellent work done as a 
result of http://legacy.python.org/dev/peps/pep-0393/, the Flexible 
String Representation, as we, with one noticable exception, are 
perfectly well aware of.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Chris Angelico]

On Fri, Apr 11, 2014 at 10:39 PM, Tim Chase
 wrote:
> On 2014-04-11 11:34, Steven D'Aprano wrote:
>> >> That's equivalent to being told "Don't ever delete any of your
>> >> code, just comment it out". I don't care who's saying that, it's
>> >> bad advice.
>> >
>> > The correct analogy: "Dont ever delete content from the
>> > repository"
>>
>> No -- the repository is the email archive. (Your inbox, perhaps.)
>> You don't keep a copy of the entire repo in every source file.
>
> Clearly you've not seen some of the corporate code-bases I've had to
> touch. «shudder»  I still have nightmares about vast swaths of code
> commented out or "#ifdef 0"ed out.
>
> Then again, since they used Visual Source Safe, it might have been
> the smarter/safer option ;-)

I think Steven was agreeing with me that it's bad advice, rather than
that it never happens... There's an expression on The Daily WTF:
"Enterprise happens". Covers this situation well, IMO.

http://thedailywtf.com/Articles/The-Enterprise-Dependency.aspx

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

 wrote:

>> It's worth noting, as an aside, that this does NOT mean you don't
>> produce or sell anything. You can keep your code secure by running it
>> on a server and permitting users to access it; that's perfectly safe.
>> 
> Perfectly?  :-)

Unless you have a heartbleed :)

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[alister]

On Thu, 10 Apr 2014 18:29:21 -0700, Wesley wrote:

> Hi all,
>   Does python has any good obfuscate?
> 
> Currently our company wanna release one product developed by python to
> our customer. But dont's wanna others see the py code.
> 
> I googled for a while but mostly just say using pyc. Any better one?
> 
> Our product is deployed on Linux bed.
> 
> Thanks.
> Wesley

As already highlighted obfuscation is probably pointless, what do you 
expect it to achieve anyway? i can see a number of reasons all of which 
can be proved futile.

1) you want to stop the customer copying the program to other computers:-
obsfucation wont help here they already have the executable file & can 
just run it anyway Many copy protection schemes have been tried in the 
past none have been sucsesull

2) you don't want the customer to be able to modify your code & pass it 
of as their own:-

This is what Copyright is for. Also if they are that poor a programming 
shop that they are desperate to steel for your code they probably wont be 
in business long anyway.

3) to stop them modifying the code to suit their own requirements:-

What on earth is the problem here, that just makes the software more 
valuable to them. As long as they are paying for your software (assuming 
it is not freeware) then everyone wins. if they are not paying then it is 
another example of Copyright breach.

4) your software is a driver for some exotic piece of hardware & reading 
the code will help produce a competing product:-

A reasonable justification but in that case it is probably still worth 
the time & effort of fully decompiling the code & reverse engineering the 
hardware and the best you will do will be to slow them down


it is my opinion that attempting to obfuscate the code is akin to 
Microsoft's improvements to the BSOD in windows 8 (Adding a frowning 
emotion) the effort would have been better spent ensuring it wasn't 
displayed in the first place. 
Concentrate on making the product (even) better rather than trying to 
hide the unhideable.

-- 
It's easy to get on the internet and forget you have a life
-- Topic on #LinuxGER
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Mark Lawrence]

On 11/04/2014 14:06, Sturla Molden wrote:

 wrote:


It's worth noting, as an aside, that this does NOT mean you don't
produce or sell anything. You can keep your code secure by running it
on a server and permitting users to access it; that's perfectly safe.


Perfectly?  :-)


Unless you have a heartbleed :)

Sturla



I was thinking more along the lines of Greek tragedies. :)

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Mark Lawrence]

On 10/04/2014 21:52, pete.bee@gmail.com wrote:




Just awesome, not only do we have double line spacing and single line

paragraphs, we've also got top posting, oh boy am I a happy bunny :)

I'll leave someone3 else to explain, I just can't be bothered.




Do you get paid to be a jerk, or is it just for yuks?  If the latter, you're 
not funny.



Lucky I didn't say anything about the dirty knife.

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

alister  wrote:

> Concentrate on making the product (even) better rather than trying to 
> hide the unhideable.

I think the number one reason for code obfuscation is an ignorant boss. 

Another reason might be to avoid the shame of showing crappy code to the
customer.


Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Mark H Harris]

On 4/10/14 3:52 PM, pete.bee@gmail.com wrote:


Do you get paid to be a jerk, or is it just for yuks?  If the latter, you're 
not funny.



Mark is the c.l.python resident margin police. Think of him as a welcome 
committee with an attitude.


:)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Mark H Harris]

On 4/10/14 10:54 AM, Lalitha Prasad K wrote:

Dear List

Recently I was requested to teach python to a group of students of GIS
(Geographic Information Systems).


   Adults?  ... what age ranges?


Their knowledge of programming is
zero. The objective is to enable them to write plug-ins for GIS software
like QGIS and ArcGIS.


   Its a fabulous idea. Integrating disciplines is the correct approach 
to computer science education in my opinion.
   From day one (and yes I was there on day one) computer science knows 
nothing about the insurance industry, and underwriters know nothing 
about programming. The way to get these two groups together is to 
integrate comp sci education with underwriting.



It would require them to learn, besides core
python, PyQt, QtDesigner. So my plan is to teach them core python, PyQt,
Qt Designer, in that order. A kind of "bottom up approach".


   Beautiful.


But the
students seem to feel that I should use "top down approach". That is,
show them how to write a plug-in, then PyQt and Qt Designer and then
enough of python so they can handle the above.


   The phrase "just enough python" is almost possible. I am working on 
a project I call SimplyPy that has this same goal in mind; but I'm not 
finished yet. But the idea is to boil the galaxy of python down to a 
small solar system with a couple of planets. If these cats are in their 
early twenties, no problem. If they really are "non programmers" it will 
be easier because they come to the table teachable. I would rather have 
twenty students "tabula rosa" than having one student who thinks they 
already know everything.




marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Mark H Harris]

On 4/10/14 8:29 PM, Wesley wrote:


   Does python has any good obfuscate?


   Others have answered this well, but I thought I would give you 
another opinion, perhaps more direct.


   Obfuscation (hiding) of your source is *bad*,  usually done for one 
of the following reasons:
   1) Boss is paranoid and fears loss of revenues due to intellectual 
property theft.
   2) Boss is ignorant of reverse engineering strategies available to 
folks who want to get to the heart of the matter.
   3) Boss and|or coders are embarrassed for clients (or other coders) 
to see their art, or lack thereof. Sometimes this is also wanting to 
hide the fact that the product really isn't "worth" the price being 
charged for it?!?


   There really is no good reason to obfuscate your code.


Currently our company wanna release one product developed by

> python to our customer. But dont's wanna others see the py code.

   This is the age of open source in computer science.

   It is far better to develop a strategy and culture of openness. 
Everyone benefits; especially your customers. I recommend the GPLv3 
license. I also advocate for copyleft. How to leverage openness for 
capital gain, you might ask? Answer: provide a value add. Its not just 
about your code, or your "product". It should also be about your 
service, maintenance, support, packing, manuals, news letters, &c.


   Deliberately obfuscating your code is a negative; please consider an 
alternative strategy.


marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Michael Torrie]

On 04/10/2014 07:29 PM, Wesley wrote:
> Hi all, Does python has any good obfuscate?
> 
> Currently our company wanna release one product developed by python
> to our customer. But dont's wanna others see the py code.
> 
> I googled for a while but mostly just say using pyc. Any better one?
> 
> Our product is deployed on Linux bed.

I guess it all depends on what you are really trying to do.

If you're trying to prevent people from making and using unauthorized
copies of your software then even obfuscating the code certainly won't
help that at all.

If you're trying to prevent people from learning trade secrets, then
simply don't put that part of your product in the hands of customers.
And on this point the language doesn't matter.  Could be a binary
compiled from C++.  Someone could, in theory, reverse-engineer and trace
the code and uncover your secret algorithm.  The question is, is it
worth it for the mythical, theoretical, bad guy to do this?  Is it worth
it for you to go to lengths to prevent this theoretical possibility?

If you have IP you truly need to keep secret, separate it out from your
application and stick it on a server and talk to it over some form of RPC.

If you're simply trying to keep the boss happy, simply wrapping up your
python scripts into a self-contained executable format (say py2exe or a
similar tool) is probably good enough.

Most end users will never know or care what you build the app with, even
if you have a directory full of open .py files.  99% of the users of a
popular ebook app called Calibre never know or care that it's made of
python and that you could go in and see the code.  All they care about
is they can click an icon and the program launches and runs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Chris Angelico]

On Sat, Apr 12, 2014 at 1:09 AM, Mark H Harris  wrote:
>This is the age of open source in computer science.
>
>It is far better to develop a strategy and culture of openness. Everyone
> benefits; especially your customers. I recommend the GPLv3 license.

While I wholeheartedly agree with the ideal of open source, I don't
like the GPL (any version), because of the annoying restrictions that
end up running through projects. All sorts of projects can't go GPL,
ergo can't use readline. Why? Because readline went for a policy of
"force it to be GPL or nothing". Thank you so much, now I have to faff
around with PostgreSQL to get decent editing keys (and the legality of
that is apparently dubious, but IANAL and it's not my problem anyway).
Postgres is open source, but not GPL, and it's linked to some other
library (I disremember which) that's under a license incompatible with
the GPL.

For my code, I use the MIT license. Do what you like, only don't sue
me. Okay, that's not something everyone will want to use, but it does
make things easier on anyone who wants to distribute it. You want to
release a third-party build of my program? Or even just package up my
code into an installer? No problem; you aren't responsible to host the
code. With GPL software, you *are*, as I found out when I tried to
make a simple GTK updater; I'm legally required to make it clear that
the source code is available from the same web site as the binaries
are (even though I didn't build it, all I did was download the
binaries from their site and download the corresponding source
archives), and I'm also obliged from the perspective of practicality
to make it clear that the source code is not necessary, lest my users
be thoroughly confused. Completely unnecessary hassle; it's red tape
applied to those who're keeping everything open, in order to have a
weapon to wield against those who close things up.

I'm aware that the GPL has its place. I'm fully aware that GPL
violations, being pursued legally, help to ensure openness; and the
borderline cases of "we could go proprietary or we could go open
source" are sometimes tipped in favour of open source by an argument
of "we could use this if we go open"; but for most people, please,
pick a simpler license that puts less restrictions on usage.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Chris Angelico]

On Sat, Apr 12, 2014 at 1:19 AM, Michael Torrie  wrote:
> Most end users will never know or care what you build the app with, even
> if you have a directory full of open .py files.  99% of the users of a
> popular ebook app called Calibre never know or care that it's made of
> python and that you could go in and see the code.  All they care about
> is they can click an icon and the program launches and runs.

Absolutely. When you run "hg something_or_other", you would expect
that it's all written in Python, but some of it might not be, for all
you know. Certainly with git there are several languages used (some
are compiled binaries, some are shell scripts, some are Perl, gitk is
TCL...), and it doesn't matter at all. Who cares? I type a command and
it runs. If upstream decides to rewrite bash in Lua, I won't much
care, and probably wouldn't even know (although somehow I suspect
performance would drop... slightly...).

Adding to your list, though:

If you're trying to hide your source code for security, absolutely DO
NOT! This is one of the most common reasons I've heard of; either
because the "cryptographic" algorithms are hand-rolled and easy to
reverse-engineer if you have the source, or because the keys are
hard-coded in the program. Either way, you can't. It just won't work.
People can get at your crypto, and if it's broken as soon as someone
sees the source code, it's weak crypto to start with.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Marko Rauhamaa]

Rustom Mody :

> On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote:
>> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote:
>> >  (1) oversimplification which makes it difficult to extend the design
>> >  and handle all of the real-world contingencies
>> 
>> This I dont...
>
> I meant "Dont understand"

The simplest example: there's no general way to terminate a thread.
Hacks exist for some occasions, but they can hardly be considered
graceful.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Steven D'Aprano]

On Fri, 11 Apr 2014 13:48:50 +0100, Mark Lawrence wrote:

> On 11/04/2014 10:25, wxjmfa...@gmail.com wrote:
>>
>> Unicode!
>>
>>
> Works perfectly in Python 3.3+ thanks to the excellent work done as a
> result of http://legacy.python.org/dev/peps/pep-0393/, the Flexible
> String Representation, as we, with one noticable exception, are
> perfectly well aware of.

Please don't bait JMF. Writing a post for the sole purpose of getting a 
reaction from others is the definition of trolling.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Chris Angelico]

On Sat, Apr 12, 2014 at 1:36 AM, Marko Rauhamaa  wrote:
> The simplest example: there's no general way to terminate a thread.
> Hacks exist for some occasions, but they can hardly be considered
> graceful.

Having followed python-list for some time now, I have to agree... you
can't terminate a thread, no matter how many posts it has in it!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Mark Lawrence]

On 11/04/2014 16:49, Steven D'Aprano wrote:

On Fri, 11 Apr 2014 13:48:50 +0100, Mark Lawrence wrote:


On 11/04/2014 10:25, wxjmfa...@gmail.com wrote:


Unicode!



Works perfectly in Python 3.3+ thanks to the excellent work done as a
result of http://legacy.python.org/dev/peps/pep-0393/, the Flexible
String Representation, as we, with one noticable exception, are
perfectly well aware of.


Please don't bait JMF. Writing a post for the sole purpose of getting a
reaction from others is the definition of trolling.



If you wish to interpret my words as baiting that's fine by me.  From my 
perspective I'm simply making a statement of fact.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Mark Lawrence]

On 11/04/2014 16:53, Chris Angelico wrote:

On Sat, Apr 12, 2014 at 1:36 AM, Marko Rauhamaa  wrote:

The simplest example: there's no general way to terminate a thread.
Hacks exist for some occasions, but they can hardly be considered
graceful.


Having followed python-list for some time now, I have to agree... you
can't terminate a thread, no matter how many posts it has in it!

ChrisA



Wro

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Chris Angelico]

On Sat, Apr 12, 2014 at 1:57 AM, Mark Lawrence  wrote:
> If you wish to interpret my words as baiting that's fine by me.  From my
> perspective I'm simply making a statement of fact.

It's almost now debatable whether you were metabaiting Steven into
telling you off for trolling the resident troll...

The time when we could have sane threads started by a jmf post about
Unicode is now over. His posts no longer have false claims that crave
rebuttal, so I advise completely ignoring them, and him, until such
time as he makes a point worthy of a response.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unpacking U-Boot image file

[Grant Edwards]

On 2014-04-10, Rhodri James  wrote:
> On Wed, 09 Apr 2014 18:18:56 +0100, Rustom Mody  wrote:
>> On Wednesday, April 9, 2014 9:36:40 PM UTC+5:30, trewio wrote:
>>
>>> How to extract files from U-Boot image file, LZMA-compressed?
>>>
>>> Is there a Python script that can do this properly?
>>
>> For lzma theres this (recent) python library
>> https://docs.python.org/dev/library/lzma.html
>>
>> Though you might just be better off with the command-line xz unxz etc
>>
>> After that.. whats the U-boot format?
>
> The Fine Manual (http://www.denx.de/wiki/view/DULG/UBootImages) isn't very  
> forthcoming, sadly;
>
> "U-Boot operates on "image" files which can be basically anything,  
> preceeded by a special header; see the definitions in include/image.h for  
> details; basically, the header defines the following image properties
>
> * Target Operating System
> * Target CPU Architecture
> * Compression Type
> * Load Address
> * Entry Point
> * Image Name
> * Image Timestamp"
>
> I suspect taking this apart may be a little involved.

Not really.  For the format you're talking about (single-file uImage),
you can extract the data like so:

  data = open("foobar.uImage","rb").read()[64:]

Then just uncompress 'data' as desired.

If you want to look at individual fields in the heaer, here's the
structure:   

#define IH_MAGIC0x27051956/* Image Magic Number */
#define IH_NMLEN32/* Image Name Length  */

typedef struct image_header 
{
  uint32_tih_magic;   /* Image Header Magic Number*/
  uint32_tih_hcrc;/* Image Header CRC Checksum*/
  uint32_tih_time;/* Image Creation Timestamp */
  uint32_tih_size;/* Image Data Size  */
  uint32_tih_load;/* Data  Load  Address  */
  uint32_tih_ep;  /* Entry Point Address  */
  uint32_tih_dcrc;/* Image Data CRC Checksum  */
  uint8_t ih_os;  /* Operating System */
  uint8_t ih_arch;/* CPU architecture */
  uint8_t ih_type;/* Image Type   */
  uint8_t ih_comp;/* Compression Type */
  uint8_t ih_name[IH_NMLEN];  /* Image Name   */
} image_header_t;

Header fields are all in network byte order (bit-endian).

However, there's also a "multi-file" uImage format that I suspect is
what the OP is referring to (since he says he needs to extract "files"
from a uImage file).

http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/

In that case, the "Image Type" field will be set to 4, and the 'data'
field starts with a list of 32-bit image size values (network byte
order, terminated by 0x).  That list is then followed by the
image data.

Here's a Python 2.7 program that reads the uImage header, prints some
stuff and then reads the data for the image(s).  What to _do_ with the
data for the image(s) is left as an exercise for the gentle reader.

-8<-
#!/usr/bin/python

import sys,struct

f = open(sys.argv[1],"rb")

(ih_magic, ih_hcrc, ih_time, ih_size, ih_load, ih_ep, ih_dcrc, 
 ih_os, ih_arch, ih_type, ih_comp, ih_name) \
= struct.unpack("!III32s",f.read(64))

print "magic=%08x type=%d size=%d name='%s'" % (ih_magic, ih_type, ih_size, 
ih_name)

if ih_type == 4:
# multi-file: read image lengths from data
imagesizes = []
while 1:
size, = struct.unpack("!I",f.read(4))
if size == 0:
break
imagesizes.append(size)
else:
# single-file
imagesizes = [ih_size]

print imagesizes

images = [f.read(size) for size in imagesizes]

print [len(image) for image in images]

extradata = f.read() 

if extradata:
print "%d bytes of extra data" % len(extradata)

-8<-










-- 
Grant Edwards   grant.b.edwardsYow! The Korean War must
  at   have been fun.
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Mark H Harris]

On 4/11/14 11:02 AM, Chris Angelico wrote:


It's almost now debatable whether you were metabaiting Steven into
telling you off for trolling the resident troll...



QOTW

--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Mark H Harris  wrote:

> This is the age of open source in computer science.
> 
> It is far better to develop a strategy and culture of openness. 
> Everyone benefits; especially your customers. I recommend the GPLv3 
> license. I also advocate for copyleft. 

I would not use GPL in a commercial product, but "Open Source" might still
be beneficial. E.g. one can get better feedback and even bug fixes or code
improvements from customers and other interested parties. It is a win-win
situation. If I ran a software business (I don't currently do), I would
gladly discount customers or pay anyone who help to improve my software.
Open Source does not mean that software has to be free, that copyright is
lost, or that copyleft is implied.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Sturla Molden]

Mark H Harris  wrote:

> Obfuscation (hiding) of your source is *bad*,  usually done for one 
> of the following reasons:
> 1) Boss is paranoid and fears loss of revenues due to intellectual 
> property theft.
> 2) Boss is ignorant of reverse engineering strategies available to 
> folks who want to get to the heart of the matter.
> 3) Boss and|or coders are embarrassed for clients (or other coders) 
> to see their art, or lack thereof. Sometimes this is also wanting to 
> hide the fact that the product really isn't "worth" the price being 
> charged for it?!?

You can also add fear of patent trolls to this list. Particularly if you
are in a startup and cannot afford a long battle in court. You can quickly
go bankrupt on attorney fees.

Sturla

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Language summit notes

[Mark Lawrence]

On 11/04/2014 17:02, Chris Angelico wrote:

On Sat, Apr 12, 2014 at 1:57 AM, Mark Lawrence  wrote:

If you wish to interpret my words as baiting that's fine by me.  From my
perspective I'm simply making a statement of fact.


It's almost now debatable whether you were metabaiting Steven into
telling you off for trolling the resident troll...

The time when we could have sane threads started by a jmf post about
Unicode is now over. His posts no longer have false claims that crave
rebuttal, so I advise completely ignoring them, and him, until such
time as he makes a point worthy of a response.

ChrisA



I have no further comment to make, regardless of who says what.

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Grant Edwards]

On 2014-04-11, Roy Smith  wrote:

> At a high level, threads and coroutines are really very similar.  They 
> are both independent execution paths in the same process.  I guess the 
> only real difference between them is that thread switching is mediated 
> by the operating system, so it can happen anywhere (i.e. at any 
> instruction boundary).

That's only true if your threading system has pre-emption. Python's
does, but not all do. If your threading system is cooperative rather
than preemptive, then using coroutines is completely idential to
threading with 2 threads.

> Coroutines scheduling is handled in user code,

As is cooperative multithreading.

-- 
Grant Edwards   grant.b.edwardsYow! My BIOLOGICAL ALARM
  at   CLOCK just went off ... It
  gmail.comhas noiseless DOZE FUNCTION
   and full kitchen!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Grant Edwards]

On 2014-04-11, Ian Kelly  wrote:
> On Thu, Apr 10, 2014 at 8:17 PM, Wesley  wrote:
>> Umm, just wanna make all .py files not human readable.
>>
>> Or, maybe need a tool like zend in php.
>
> The only reliable way to prevent a customer from reverse-engineering
> your software is to not give them the software.  For example, instead
> of giving them software containing the critical code that you want to
> protect, give them access to a web service running that code, which
> you host and control.

If you do that the odds of them obtaining your code are reduced, but
don't assume they go to 0.  ;)

-- 
Grant Edwards   grant.b.edwardsYow! I just heard the
  at   SEVENTIES were over!!  And
  gmail.comI was just getting in touch
   with my LEISURE SUIT!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Grant Edwards]

On 2014-04-11, Chris Angelico  wrote:
> On Fri, Apr 11, 2014 at 7:17 PM, Sturla Molden  
> wrote:
>> The only way to protect your code is never to ship anything.
>
> It's worth noting, as an aside, that this does NOT mean you don't
> produce or sell anything. You can keep your code secure by running it
> on a server and permitting users to access it; that's perfectly safe.

You think a server that can be accessed by untrested people can be
perfectly safe?

Oh dear.

-- 
Grant Edwards   grant.b.edwardsYow! If our behavior is
  at   strict, we do not need fun!
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Grant Edwards]

On 2014-04-11, Sturla Molden  wrote:
> alister  wrote:
>
>> Concentrate on making the product (even) better rather than trying to
>> hide the unhideable.
>
> I think the number one reason for code obfuscation is an ignorant
> boss. 
>
> Another reason might be to avoid the shame of showing crappy code to
> the customer.

Another reason I've heard of is to try to reduce support efforts.

If you distribute something that's easy to modify, then people will.

And when it doesn't work, they'll call tech support and waste
everybody's time trying to track down bugs that aren't actually _in_
the product you're shipping.

-- 
Grant Edwards   grant.b.edwardsYow! In Newark the
  at   laundromats are open 24
  gmail.comhours a day!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Rustom Mody]

On Friday, April 11, 2014 5:04:28 PM UTC+5:30, Steven D'Aprano wrote:
> I've been in plenty of mailing list forums where interleaved posting was
> required, but there's only so many times you can tell people off for
> being rude before you start coming across as rude yourself.

> It's one of those nasty aspects of human psychology: the guy who casually
> and without malice tosses litter out of his car window, spoiling things
> for everyone, is somehow considered less obnoxious than the person who
> tells him off. Except in Switzerland, where if you leave your rubbish bin
> out more than twenty minutes after its been emptied, the neighbours
> consider it perfectly acceptable to tell you off, never mind that you've
> been at work. And heaven help you if you take your discarded Christmas
> tree down to the street too early.

Yes this is correct: we make the world a worse place by choosing to
be 'nice guys' when some telling off would help. And I am remiss on this
matter since I dont post that python-google-groups link when I should.  [Can
never find the damn link when needed though I wrote half of it myself!]

For the rest, Im not sure that you need my help in making a fool of yourself...
Anyway since you are requesting said help, here goes:

> On Thu, 10 Apr 2014 22:42:14 -0700, Rustom Mody wrote:
> 
> 
> > People whose familiarity with religion is limited to the Judeo-Christian
> > tradition are inclined to the view (usually implicit) that "being
> > religious" == "belief in God"
> > However there are religions where belief in God is irreligious --
> 
> > Jainism 
> 
> I think that it will come as rather a surprise to Jains to be told that 
> they don't believe in god. In fact, they believe in a multitude of gods 
> (not surprising, as Jainism is derived from Hinduism) and believe that 
> every soul has the potential to become a god. 

http://en.wikipedia.org/wiki/God_in_Jainism
and particularly
http://en.wikipedia.org/wiki/God_in_Jainism#Heavenly_Beings


> > And others where it is is irrelevant -- Tao, Shinto. [There is
> > the story of a westerner who wen to a shinto temple and said: All this
> > (rites) is fine and beautiful but what's your *philosophy* To which he
> > was told: "Philosophy? We have no philosophy! We dance!"]
> 
> A nice story, but the name "Shinto" even means "The Way Of The Gods", so 
> claiming that Shinto is not about gods is rubbish.

http://books.google.co.in/books?id=b-VACc7jcOAC&lpg=PA159&ots=femTbp96rh&dq=shinto%20%22We%20have%20no%20philosophy%22%20we%20dance&pg=PA159#v=onepage&q=shinto%20%22We%20have%20no%20philosophy%22%20we%20dance&f=false


> > In middle-eastern society women are expected to dress heavier than in
> > the West. A few years ago a girl went to school in France with a scarf
> > and she was penalized.
> 
> Citation please. I think this is bogus, although given how obnoxious some 
> schools can be I'm not quite prepared to rule it out altogether. I think 
> it's far more likely that she was only penalized for wearing full head-
> covering (not just a scarf) after being warned that it was not part of 
> the school uniform and therefore not appropriate.

In spite of Paul pointing out the link (thanks Paul)

http://en.wikipedia.org/wiki/Islamic_scarf_controversy_in_France

you still persist in

> in this specific case, I stand by my skepticism

So you think that wikipedia link/article is bogus?



Anyway.. To come back to the point of those examples:

You are welcome to your view:

> I don't know that there is anyone here that thinks interleaved posting is
> the norm among the majority of email users. Nor is anyone saying that
> Usenet posters make up a majority of internet users. What we are saying
> is that *interleaved posting is objectively better* for most forms of
> email or news communication (although it is not a panacea), and
> especially for *technical discussions* like those that occur here.

All those examples were adduced only to say that like matters of dress and 
matters of God-belief are not absolute standards in any frame, in any sense,
so also mail etiquette.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Rustom Mody]

On Friday, April 11, 2014 9:06:47 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody:
> > On Friday, April 11, 2014 10:45:08 AM UTC+5:30, Rustom Mody wrote:
> 
> >> On Friday, April 11, 2014 2:14:42 AM UTC+5:30, Marko Rauhamaa wrote:
> 
> >> >  (1) oversimplification which makes it difficult to extend the design
> >> >  and handle all of the real-world contingencies
> >> 
> >> This I dont...

> The simplest example: there's no general way to terminate a thread.
> Hacks exist for some occasions, but they can hardly be considered
> graceful.

I was about to say that this is fairly close to my point, viz:

Half-assed support in current languages does not imply any necessary problem
in the idea -- just in the mainstream implementations of it.

Then looking it up I find Go's goroutines have the same issue.
Erlang processes though, are kill-able like quite any unix process
http://www.erlang.org/doc/reference_manual/processes.html#id85098

What does that mean?? I am not quite sure... It may mean that Steven's

> I think coroutines are awesome, but like all advanced concepts, sometimes
> they can be abused, and sometimes they are hard to understand not because
> they are hard to understand in and of themselves, but because they are
> being used to do something inherently complicated.

is right.

Personally my view is the other way round:

Concurrency (generalizing from coroutines) is not hard.
The problem is that imperative programming and concurrency are deeply 
incompatible because imperative programming is almost by definition
sequential programming and concurrency is by definition concurrent,
ie non-sequential

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: threading

[Marko Rauhamaa]

Rustom Mody :

> Half-assed support in current languages does not imply any necessary
> problem in the idea -- just in the mainstream implementations of it.
>
> Then looking it up I find Go's goroutines have the same issue.

the promise of threads is that you only need to consider a single event
out of any given state. Trouble is, in reality, you need ot consider a
multitude of events in every state. Threads are not good at presenting
that reality.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[pete . bee . emm]

On Thursday, April 10, 2014 3:40:22 PM UTC-7, Rhodri James wrote:
> It's called irony, and unfortunately Mark is reacting to an all-to-common  
> situation that GoogleGroups foists on unsuspecting posters like yourself.   

People who say "I can't be bothered to correct this" while posting a wise a$$ 
correction are just trolling, probably not funny in real life either. I think 
if you're going to wise off than be witty about it, otherwise just a terse 
reference to a link.

At any rate, my original point stands. You're not teaching on planet Vulcan. 
Better to teach things in an odd order if that helps motivates your students. 
It's not like people in real life carefully examine all available documentation 
before learning some piece of tech. Usually they shrug and say "what's the 
worst that could happen", dive in, and roll with the consequences.
-- 
https://mail.python.org/mailman/listinfo/python-list

indexing in format strings

[blindanagram]

With:

   l = [1,2,3]

this:

   print('{0[0]:d}..{0[2]:d}'.format(l))

gives 1..3 but this:

   print('{0[0]:d}..{0[-1]:d}'.format(l))

gives:

   Traceback (most recent call last):
File "", line 1, in 
   builtins.TypeError: list indices must be integers, not str

which seems to me counterintuitive.

I expected indexing in a format string to behave as it does elsewhere
but this seems not to be true.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: indexing in format strings

[Mark Lawrence]

On 11/04/2014 22:33, blindanagram wrote:

With:

l = [1,2,3]

this:

print('{0[0]:d}..{0[2]:d}'.format(l))

gives 1..3 but this:

print('{0[0]:d}..{0[-1]:d}'.format(l))

gives:

Traceback (most recent call last):
 File "", line 1, in 
builtins.TypeError: list indices must be integers, not str

which seems to me counterintuitive.

I expected indexing in a format string to behave as it does elsewhere
but this seems not to be true.



See http://bugs.python.org/issue7951

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: indexing in format strings

[Terry Reedy]

On 4/11/2014 5:33 PM, blindanagram wrote:

With:

l = [1,2,3]

this:

print('{0[0]:d}..{0[2]:d}'.format(l))

gives 1..3 but this:

print('{0[0]:d}..{0[-1]:d}'.format(l))

gives:

Traceback (most recent call last):
 File "", line 1, in 
builtins.TypeError: list indices must be integers, not str

which seems to me counterintuitive.

I expected indexing in a format string to behave as it does elsewhere
but this seems not to be true.


Been discussed on the tracker. Consider:

>>> '{0[-1]}'.format({'-1': 'neg int key'})
'neg int key'

Not quoting string keys within the format string introduces ambiguity 
settled by 'string unless all digits, then int'.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Joshua Landau]

On 11 April 2014 10:17, Sturla Molden  wrote:
> Joshua Landau  wrote:
>
>> However, if this really is your major blocker to using Python, I
>> suggest compiling with Cython.
>
> Cython restains all the code as text, e.g. to readable generate exceptions.
> Users can also still steal the extension modules and use them in their own
> code. In general, Cython is not useful as an obfuscation tool.

Ah, thanks for the info. I imagine it's perfectly easy to get around
that, though, through basic removal at the C phase. I doubt it's
worthwhile doing so, but deobfuscation will still be harder than a
.pyc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: indexing in format strings

[blindanagram]

On 11/04/2014 22:33, blindanagram wrote:

Thanks, Mark and Terry, for your rapid responses.

An interesting thread.

   Brian

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Steven D'Aprano]

On Fri, 11 Apr 2014 16:27:27 +, Grant Edwards wrote:

> Another reason I've heard of is to try to reduce support efforts.
> 
> If you distribute something that's easy to modify, then people will.

The majority of people will treat your app as a black box. Of course, a 
small minority (either out of actual competence, or sheer incompetence) 
will try to modify anything supplied as source code. (And who is to say 
that they shouldn't be permitted to, if they've bought your product?)

> And when it doesn't work, they'll call tech support and waste
> everybody's time trying to track down bugs that aren't actually _in_ the
> product you're shipping.

I wonder whether Red Hat and Ubuntu have this problem? Somehow I think 
that the magnitude of it is grossly exaggerated.

But in any case, this at least is trivially solved: take the md5 of your 
application, then before doing any support check whether the md5 of their 
copy has changed. A tiny Python script (small enough to visually inspect) 
can do this on systems without a md5sum utility.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Rustom Mody]

On Saturday, April 12, 2014 1:50:05 AM UTC+5:30, pete.b...@gmail.com wrote:
> On Thursday, April 10, 2014 3:40:22 PM UTC-7, Rhodri James wrote:
> 
> > It's called irony, and unfortunately Mark is reacting to an all-to-common  
> > situation that GoogleGroups foists on unsuspecting posters like yourself.   
> 
> 
> 
> People who say "I can't be bothered to correct this" while posting a wise a$$ 
> correction are just trolling, probably not funny in real life either. I think 
> if you're going to wise off than be witty about it, otherwise just a terse 
> reference to a link.

Thanks Pete for taking the trouble for aligning your posting style with
the norms expected out here.

On problem -- the over long lines -- remains.

If you compare your post
https://mail.python.org/pipermail/python-list/2014-April/670693.html

with typical neighboring others, you will see that.

[Just for the record I should mention that I did not know this to be a problem
for a long time until someone pointed it out to me.
]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Teaching python to non-programmers

[Steven D'Aprano]

On Fri, 11 Apr 2014 11:19:22 -0700, Rustom Mody wrote:

> On Friday, April 11, 2014 5:04:28 PM UTC+5:30, Steven D'Aprano wrote:
[...]
> For the rest, Im not sure that you need my help in making a fool of
> yourself... Anyway since you are requesting said help, here goes:

Very strong words.


>> On Thu, 10 Apr 2014 22:42:14 -0700, Rustom Mody wrote:
>> 
>> 
>> > People whose familiarity with religion is limited to the
>> > Judeo-Christian tradition are inclined to the view (usually implicit)
>> > that "being religious" == "belief in God"
>> > However there are religions where belief in God is irreligious --
>> 
>> > Jainism
>> 
>> I think that it will come as rather a surprise to Jains to be told that
>> they don't believe in god. In fact, they believe in a multitude of gods
>> (not surprising, as Jainism is derived from Hinduism) and believe that
>> every soul has the potential to become a god.
> 
> http://en.wikipedia.org/wiki/God_in_Jainism and particularly
> http://en.wikipedia.org/wiki/God_in_Jainism#Heavenly_Beings


- You state that in Jainism, belief in god (which one?) is
  "irreligious" (i.e. hostile to religion);

- I point out that in the case of Jains, belief in many gods is 
  in fact a core part of their religion;

- you attempt to refute me by linking to an article which confirms 
  that belief in gods is part of Jainism.

And that's supposed to prove that I'm wrong?

Perhaps you think that "belief in gods" is ipso facto the same as 
"worshipping those gods"? That's an awfully naive view, especially for 
someone who started this discussion by complaining about the naivety of 
other people's understanding of religion.


>> > And others where it is is irrelevant -- Tao, Shinto. [There is the
>> > story of a westerner who wen to a shinto temple and said: All this
>> > (rites) is fine and beautiful but what's your *philosophy* To which
>> > he was told: "Philosophy? We have no philosophy! We dance!"]
>> 
>> A nice story, but the name "Shinto" even means "The Way Of The Gods",
>> so claiming that Shinto is not about gods is rubbish.
> 
> http://books.google.co.in/books?id=b-
VACc7jcOAC&lpg=PA159&ots=femTbp96rh&dq=shinto%20%22We%20have%20no%
20philosophy%22%20we%20dance&pg=PA159#v=onepage&q=shinto%20%22We%20have%
20no%20philosophy%22%20we%20dance&f=false

What's this supposed to prove? It's a nice story. The book you linked to 
doesn't give any more details than you do, it even states "A story is 
told". It's an unnamed philosopher, an unnamed priest from an anonymous 
temple. There is *absolutely nothing* suggesting it ever happened in real 
life, but even if it did, it certainly doesn't suggest anything about 
Shinto. If anything, it's about the ignorance of the supposed American 
philosopher.

Did you think I was questioning the existence of the story? I said 
nothing to suggest you made the story up (although it seems to me that 
the author you quote probably did). I don't question the existence of the 
story. I question that the story is meaningful.

It seems to me that only somebody *completely ignorant of Shinto* can 
possible think that Shinto in general has no philosophy or religious 
meaning. Shinto, as a glorified (literally) folk-religion, may lack the 
sort of over-arching grand philosophies of (say) the Catholic Church, but 
I think it is an astonishingly foolish thing to suggest that all they do 
is dance. Even figuratively.


>> > In middle-eastern society women are expected to dress heavier than in
>> > the West. A few years ago a girl went to school in France with a
>> > scarf and she was penalized.
>> 
>> Citation please. I think this is bogus, although given how obnoxious
>> some schools can be I'm not quite prepared to rule it out altogether. I
>> think it's far more likely that she was only penalized for wearing full
>> head- covering (not just a scarf) after being warned that it was not
>> part of the school uniform and therefore not appropriate.
> 
> In spite of Paul pointing out the link (thanks Paul)
> 
> http://en.wikipedia.org/wiki/Islamic_scarf_controversy_in_France
> 
> you still persist in
> 
>> in this specific case, I stand by my skepticism
> 
> So you think that wikipedia link/article is bogus?

That article supports what I stated: the three girls (not one) were not 
penalized without warning for merely turning up to school with scarves. 
They were penalized for refusing to remove their hajibs, which were 
against the school's dress code.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: module version number support for semver.org

[Jörn Hees]

On 11 Apr 2014, at 01:34, Terry Reedy  wrote:

> On 4/10/2014 6:45 PM, Jörn Hees wrote:
>> what do you think about officially supporting Semantic Versioning?
>> (http://semver.org  )
> 
> It is a nice fantasy.

;) didn’t say it’s perfect, just that it’s widely used and we should support it.
I like the “fantasy" as it at least tries to give some kind of a meaning to 
version numbers.
Sorry for not going into the details here, but that would quickly lead away 
from my main point.


> This is not to say that Semver does not improve the situation when it can be 
> used.

I definitely think it does, i’ll count that as half a vote for it ;)

j

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: indexing in format strings

[Terry Reedy]

On 4/11/2014 7:13 PM, blindanagram wrote:

On 11/04/2014 22:33, blindanagram wrote:

Thanks, Mark and Terry, for your rapid responses.

An interesting thread.


It just occurred to me today, and I verified, that '+1' is also seen as 
a string.


>>> '{0[-1]}'.format({'-1': 'neg int key'})
'neg int key'
>>> '{0[+1]}'.format({'+1': 'neg int key'})
'neg int key'
>>> '{0[+1]}'.format([1,2,3])
Traceback (most recent call last):
  File "", line 1, in 
'{0[+1]}'.format([1,2,3])
TypeError: list indices must be integers, not str


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[Ben Finney]

Steven D'Aprano  writes:

> On Fri, 11 Apr 2014 16:27:27 +, Grant Edwards wrote:
>
> > Another reason I've heard of is to try to reduce support efforts.
> > 
> > If you distribute something that's easy to modify, then people will.
>
> The majority of people will treat your app as a black box. Of course, a 
> small minority (either out of actual competence, or sheer incompetence) 
> will try to modify anything supplied as source code.

Further, those who are motivated to modify the product they receive from
you will often have motivations that remain even in the absence of
source code.

In many cases that motivation is strong enough they will *still* modify
the product in an attempt to get it to do what they want. So in those
cases, even the total absence of source code is not achieving the
putative goal of “stop the recipient from modifying the product”.

> (And who is to say that they shouldn't be permitted to, if they've
> bought your product?)

Indeed. People in the position of selling something to a customer need
to stop trying to have it both ways: Either the vendor owns the product,
or the customer does.

Either the customer is paying to own the product, and thereby has full
rights to use that product and modify it and sell it on to other people
without the vendor having any further say in the matter; or: The
vendor continues to own the product even while the customer possesses
it, and is responsible for controlling how it's used and is culpable for
any harmful effects of that use.

A third way is possible, but fans of obfuscation probably won't like it:
Software is inherently not amenable to the limits of scarce physical
property at all, and attempts to treat it as scarce and exclusive and
“owned” by one party are futile and counter to physical laws.

This is the position taken by Thomas Jefferson in 1813: “If nature has
made any one thing less susceptible than all others of exclusive
property, it is the action of the thinking power called an idea.”

http://questioncopyright.org/>

-- 
 \  “By instructing students how to learn, unlearn, and relearn, a |
  `\ powerful new dimension can be added to education.” —Alvin |
_o__)Toffler, _Future Shock_, 1970 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python obfuscate

[CM]

On Friday, April 11, 2014 12:13:47 PM UTC-4, Sturla Molden wrote:
> Mark H Harris  wrote:
> 
> > Obfuscation (hiding) of your source is *bad*,  usually done for one 
> > of the following reasons:
> 
> > 1) Boss is paranoid and fears loss of revenues due to intellectual 
> > property theft.
> > 2) Boss is ignorant of reverse engineering strategies available to 
> > folks who want to get to the heart of the matter.
> > 3) Boss and|or coders are embarrassed for clients (or other coders) 
> > to see their art, or lack thereof. Sometimes this is also wanting to 
> > hide the fact that the product really isn't "worth" the price being 
> > charged for it?!?
> 
> You can also add fear of patent trolls to this list. Particularly if you
> are in a startup and cannot afford a long battle in court. You can quickly
> go bankrupt on attorney fees.
> 
> Sturla

You're saying that fear of patent trolls is yet another bad reason to 
obfuscate your code?  But then it almost sounds like you think it is a 
justifiable reason. So I don't think I understand your point.  Whether a 
patent troll has your original code or not has no bearing on the patent
infringement.  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interleaved vs. top-posting

[Bob Martin]

in 720726 20140411 134419 Tim Chase  wrote:
>On 2014-04-11 13:59, Chris Angelico wrote:
>> I have seen plenty of cultures where people are unaware of the value
>> of interleaved/bottom posting, but so far, not one where anyone has
>> actually required it. Not one.
>
>The only time I've seen top-posting required (though there was
>nothing about trimming/dropping the content from the bottom) was on
>some lists for blind users where they wanted the new content at the
>top of the email rather than having to wade through lots of content
>they'd heard previously.  The actual context was usually either given
>by in-sentence referencing to the topic, or the subject-heading
>(blind folks seem to have an incredible memory for things sighted
>folks are usually too lazy to remember).

I read IBM's internal forums from 1978 on (on VM/CMS).
Top posting was the norm where quoted text was included, though
quoting wasn't necessary as there was a means to display the post
being answered.
-- 
https://mail.python.org/mailman/listinfo/python-list