Re: Useless expressions [was Re: Undefined behaviour in C]

[Chris Angelico]

On Mon, Mar 28, 2016 at 1:59 PM, Tim Chase
 wrote:
> On 2016-03-28 12:38, Chris Angelico wrote:
>> I would still look askance at code that adds two things and drops
>> the result, though. The compiler can't discard it, but if a linter
>> complains, I'd support that. A DSL that requires you to do this is,
>> imo, poorly designed.
>
> Is it only the "*add* two things" or are you decrying any generic
> operator that gets evaluated and then drops the result?
>
> Steven recently opened a thread ["Bash-like pipes in Python"] where
> this exact sort of thing would be done:
>
>   get_values() | filter("smith") | sort("income") | send_to_printer()
>
> Several different solutions were posited with varying degrees of
> conciseness-vs-pythonicity-vs-pipe'ness.

I was talking about any operator that, for built-in types, does no
mutation and has no effect aside from its return value. So yes, the
use of the pipe is a perfect counter-example - or rather, proof that
my concern is a code smell rather than fundamentally bad. C++ started
it with the iostream << and >> overloads; personally, I think that's
more cute than useful, but there are times when it can be extremely
useful.

So I revise my stance: A DSL that requires you to do this *may be*
poorly designed, and needs a very solid justification.

> That said, I'm in the "let the compiler accept valid syntax; leave it
> to the linter" camp.

Yeah definitely.

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

Re: Useless expressions [was Re: Undefined behaviour in C]

[Tim Chase]

On 2016-03-28 12:38, Chris Angelico wrote:
> I would still look askance at code that adds two things and drops
> the result, though. The compiler can't discard it, but if a linter
> complains, I'd support that. A DSL that requires you to do this is,
> imo, poorly designed.

Is it only the "*add* two things" or are you decrying any generic
operator that gets evaluated and then drops the result?

Steven recently opened a thread ["Bash-like pipes in Python"] where
this exact sort of thing would be done:

  get_values() | filter("smith") | sort("income") | send_to_printer()

Several different solutions were posited with varying degrees of
conciseness-vs-pythonicity-vs-pipe'ness.

That said, I'm in the "let the compiler accept valid syntax; leave it
to the linter" camp.

-tkc



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

Useless expressions [was Re: Undefined behaviour in C]

[Steven D'Aprano]

On Mon, 28 Mar 2016 01:43 am, BartC wrote:

[... talk about function and procedures ...]
> Well, that could be done in Python (not so usefully because you can't
> take account of such info until a call is attempted), but that's not
> what I'm talking about, which is simply allowing:
> 
>fn(...)
> 
> whether fn has an explicit return or not, and not allowing:
> 
>fn # and other kinds of expression
> 
> unless some keyword is used. (I've no idea what that might be; all the
> best ones are taken. But I've already said a keyword can be emulated via
> a dummy function call.)


I think that the only suggestion that might, *just barely*, work in Python
is forbidding the evaluation of a single name as a syntax error. Any other
expression would have to still be allowed.

Advantage:

- catches various errors, such as forgetting to call 
  procedure-like functions:

main  # oops, meant main()


  or mistyping a keyword:

for x in sequence:
if condition: next  # oops, meant continue



Disadvantages:

- makes it less convenient to use the `try: name except NameError` idiom.

- won't do anything about errors like this:

   x = y  # oops, meant to call y()
   a = b  # this one is okay though

- it treats a single name as a special case of arbitrary 
  expressions. What's so special about the single name case
  that we should guard against this:

name

  but not this?

name.validate


The Zen of Python has something to say about special cases.

import this



Now, I happen to think that using "name.validate" for the side-effects of
the attribute look-up is a terrible idea. But it's legal code, and the
compiler shouldn't make value judgements about good or bad code. You want
value judgements, use a linter.



-- 
Steven

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

Re: Useless expressions [was Re: Undefined behaviour in C]

[Chris Angelico]

On Mon, Mar 28, 2016 at 12:24 PM, Steven D'Aprano  wrote:
>>
>>f() # Probably OK
>>g() # Probably OK
>>f()+g() # Probably not OK
>
> You don't and can't know what's "probably not" okay unless you know what
> type of object both f and g return.
>
> Don't think about floats and ints and strings. Think of complex objects with
> operator overloading. You're probably thinking of `x + y`. Instead, think
> of things like:
>
> graph + node
> database + table
>
> in a procedural style instead of a functional style. With operator
> overloading, we have the ability to write domain-specific little languages.

I would still look askance at code that adds two things and drops the
result, though. The compiler can't discard it, but if a linter
complains, I'd support that. A DSL that requires you to do this is,
imo, poorly designed. It'll make every subsequent maintainer wonder if
the code is buggy or not.

But it's still...

> ... not the compiler's job to cast value judgements on what is good or
> likely style, it must accept anything legal. If you want something to make
> value judgements about style, or get warnings about what looks like legal
> code but might be an error, then you should use a linter like PyChecker,
> Pylint, Jedi or similar. That's not the compiler's job.

Exactly.

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

Re: Statements as expressions [was Re: Undefined behaviour in C]

[Paul Rubin]

Steven D'Aprano  writes:
> if condition:
> print(1)
> print(2)
> else:
> print(3)
> print(4)
> what value should it return? Justify your choice.

It could whatever value that the last call to print() returns.  Lisp
has worked like that since the 1950's.

> What should be the return value of this statement?
>
> while True:
> x += 1
> if condition: break

It could return None, or break(val) could return val.

> I don't think that "every statement is an expression" is conceptually
> simpler at all. I think it is more difficult to understand. 

It hasn't been a problem in Lisp or its descendants, Erlang, Haskell,
etc.  I don't know about Ruby or Javascript.

> But it is even harder to understand what it might mean for a while
> loop to be a value, and the benefit of doing so seems significantly
> less than compelling.

It means that you get to use an incredibly simple and beautiful
evaluation model.  Have you ever used Lisp or Scheme?  Give it a try
sometime.  Excellent free book: 
  https://mitpress.mit.edu/sicp/full-text/book/book.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Useless expressions [was Re: Undefined behaviour in C]

[Steven D'Aprano]

On Mon, 28 Mar 2016 03:39 am, Terry Reedy wrote:

> On 3/27/2016 11:48 AM, Ned Batchelder wrote:
>> On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> 
>>> whether fn has an explicit return or not, and not allowing:
>>>
>>> fn # and other kinds of expression
>>>
>>> unless some keyword is used.
>>
>> Python *could* have made it an error to have a useless expression as a
>> statement.
> 
> In interactive mode, which is an essential part of Python, expression
> statements print the value of the expression.  Thus no expression is
> useless.
> 
> So Bart is proposing 

I don't think Bart is intending this as an actual proposal to change Python
so much as just a hypothetical to discuss.


> to either disable an extremely useful feature or 
> split Python into two slightly different dialects.  I think both are bad
> ideas.

I don't think that's quite fair. The interactive interpreter is already
slightly different from non-interactive use, in that bare expressions print
the result, while in non-interactive use they just get garbage collected.
It wouldn't be that different to change "print versus ignore" into "print
versus raise error". I think it is a bit extreme to call that two different
dialects. If so, then the current interactive interpreter is also a
different dialect.

But that's not what makes this a bad idea.

Consider something like file.write. In Python 2, writing to a file behaves
like a procedure, and you write:

with open(filename) as file:
file.write("something")


In Python 3, the write method has changed to return the number of characters
or bytes actually written. But if you don't need that information, you
aren't *forced* to collect it and ignore it. You can just ignore it:

with open(filename) as file:
file.write("something")

is still perfectly legal. But Bart's suggestion would make that an error.

No, Bart's suggestion is perfectly reasonable for a linter, but not for
Python. Other languages may choose to be more restrictive. Pascal, for
example, requires you to declare subroutines as functions or procedures
depending on whether or not they return a value, and that's got much to
recommend it too. But Python made different choices.


-- 
Steven

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

Re: How to make Python interpreter a little more strict?

[Steven D'Aprano]

On Mon, 28 Mar 2016 07:49 am, BartC wrote:

> On 27/03/2016 21:32, Tim Chase wrote:
>> On 2016-03-27 14:28, Steven D'Aprano wrote:
> 
>>> In this case, the two lines "fnc" and "next" simply look up the
>>> function names, but without actually calling them. They're not
>>> quite "no-ops", since they can fail and raise NameError if the name
>>> doesn't exist, but otherwise they might as well be no-ops.
>>
>> Which is actually useful.  I've got some 2.4 code that reads
>>
>>try:
>>  any
>>except NameError:
>>  def any(...):
>>...
>>
>> (with a similar block for all() )
>>
>> I don't want to call any() or all(), I simply want to test whether
>> they exist.
> 
> But would it have been much of an imposition to have typed:
> 
>  try:
>test = any
>  except NameError:
>def any(...):
>  ...
> 
> ? (Or any of the half dozen ways there must be to test the existence of
> a name.)

No, not much of an imposition. But then you might have your linter (if you
bother with one) complaining that you define "test" but never use it.

But regardless of whether it is an imposition or not, that's not how we do
it. It's a stylistic choice, that's all. We've explained the reasons for
it, but it ultimately comes down to a matter of taste.



-- 
Steven

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

Useless expressions [was Re: Undefined behaviour in C]

[Steven D'Aprano]

On Sun, 27 Mar 2016 10:31 pm, BartC wrote:

> On 27/03/2016 07:34, Paul Rubin wrote:
>> BartC  writes:
>>>   But my suggestion was to have required a keyword in front of
>>> such expressions.
>>
>> Should there be a keyword in front of a line containing "sqrt(x)" ?
>> What about "launch(missiles)" ?
> 
> They both look like function calls. Function calls are *very* commonly
> used as standalone expressions.
> 
> You /could/ stipulate that they be written:
> 
>call launch(missiles)# like Fortran iirc
> 
> but that wouldn't be popular and is unnecessary.
> 
>> The compiler can't tell which of those expressions has a side effect.
>> The first might be buggy code but the second is idiomatic.
> 
> Whether there are side-effects is not quite as important as picking up
> things that are likely to be errors:
> 
>f() # Probably OK
>g() # Probably OK
>f()+g() # Probably not OK

You don't and can't know what's "probably not" okay unless you know what
type of object both f and g return.

Don't think about floats and ints and strings. Think of complex objects with
operator overloading. You're probably thinking of `x + y`. Instead, think
of things like:

graph + node
database + table

in a procedural style instead of a functional style. With operator
overloading, we have the ability to write domain-specific little languages.

It's not the compiler's job to cast value judgements on what is good or
likely style, it must accept anything legal. If you want something to make
value judgements about style, or get warnings about what looks like legal
code but might be an error, then you should use a linter like PyChecker,
Pylint, Jedi or similar. That's not the compiler's job.


> Maybe there is some legitimate, obscure reason for writing the latter,
> but stick some indicator in front to tell the language (and whoever
> happens to be reading the code) that this is what you intend.

In your language, you can make operator overloading illegal if you like, or
discourage it by requiring special syntax, but in Python it is a
first-class (pun not intended) programming style of equal standing to
arithmetic, strings, method calls and modules.



-- 
Steven

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

Re: Suggestion: make sequence and map interfaces more similar

[Steven D'Aprano]

On Mon, 28 Mar 2016 05:01 am, Marco S. wrote:

> Steven D'Aprano wrote:
> 
>> The point you might have missed is that treating lists as if they were
>> mappings violates at least one critical property of mappings: that the
>> relationship between keys and values are stable.
> 
> 
> This is true for immutable maps, but for mutable ones, you can simply do

No, it is true for mutable maps too.

When you add a new key:value to a dict, the other key:value pairs don't
change. That is the whole point of a mapping! Of course you can
deliberately change the value by re-assignment:

map[key] = new_value

but that's not what I'm talking about. When you add a NEW key, the OTHER
keys DON'T change. That is ABSOLUTELY CRITICAL to a mapping. Anything which
lacks that property is not a mapping.

The relationship between the index of a value and the value in a sequence is
not stable. Inserting a new value can change the "key"(actually index) of
some or all of the existing values. The whole point of sequences is that
the position of values is NOT stable: they are intended to move around. You
can sort them, reverse them, delete them, insert new values, and the others
will move around to make room. If you think of the index as a key, this is
completely the opposite behaviour of mappings.

In a mapping, the key:value is stable, and must not change unless you
explicitly change it.

In a sequence, the index:value relationship is unstable, and can easily
change without notice, due to many different operations:

insertion
deletion
popping a value
sorting
shuffling
reversal of the sequence

and probably more.



-- 
Steven

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

Statements as expressions [was Re: Undefined behaviour in C]

[Steven D'Aprano]

On Mon, 28 Mar 2016 03:58 am, BartC wrote:

>> One of Guido's principles in designing Python was to keep it simple,
>> even where that might mean people could make errors with it.  This part
>> of the language is no different: any expression can be a statement.
> 
> Yeah, but even simpler would be that any statement can also be an
> expression! He didn't go that far though.

People say that, but I don't believe it. What does it mean to say that any
statement could also be an expression? If this statement is an expression:


if condition:
print(1)
print(2)
else:
print(3)
print(4)


what value should it return? Justify your choice.


What should be the return value of this statement?

while True:
x += 1
if condition: break


I don't think that "every statement is an expression" is conceptually
simpler at all. I think it is more difficult to understand. Nearly all
human languages make a distinction between things and actions:

* expressions return a value, which makes them a thing (noun);

* statements do something, which makes them an action (verb).


It's easy to understand the concept of an expression where the result is
dropped. "Hand me that hammer" and then you just drop the hammer on the
floor.

It's harder to understand the concept of functions (doing words, verbs) as
values. "First class functions" take a bit of mental effort to understand,
but the payoff it worth it.

But it is even harder to understand what it might mean for a while loop to
be a value, and the benefit of doing so seems significantly less than
compelling. Maybe it is easier for non-English speakers with quite
different linguistic models, but the benefit of adding statements as
expressions seems to me to be well less than the extra difficulty it would
produce.



-- 
Steven

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

Re: help with program

[Steven D'Aprano]

On Mon, 28 Mar 2016 01:18 am, Bob Gailer wrote:

> The problem with putting input at the end of a program is: if the program
> raises an exception you won't see it.

True. But the solution to that is simple: don't make mistakes when
programming :-)

If you have a better solution, please speak up. I don't know Windows very
well and I'm not sure why the console is disappearing in the first place.


-- 
Steven

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

Re: List of Functions

[Ben Bacarisse]

Richard Riehle  writes:

> Several months ago, I posted a question regarding how to create a list
> of functions.

> I realize that this seems trivial to many experience Pythonistas.  But
> it might prove useful for those who are relative newcomers to the
> language.  In any case, I hope someone can find it helpful.
>
 def button1(number):
>   print ('button1 = ', number)  ## define the buttons
 def button2(number):
>   print ('button2 = ', number)
 def button3(number):
>   print ('button3 = ', number)
 buttonList = [button1, button2, button3]  ## create the list

 buttonList [1] (25)  ## using positional association
> button2 =  25
buttonList [0] (number = 78)  ## using named association
> button1 = 78

Anywhere you see a pattern there is the opportunity to make a function
that captures the pattern.  You could choose to have a button-function
making function like this:

  def makeButton(n):
  return lambda number: print('button%d = %d' % (n, number))

It's shame that anonymous functions (for that's what's being returned
here -- a function with no name) were born of a subject that used
arbitrary Greek letters for things.  We seem stuck with the mysterious
but meaningless "lambda" for a very simple and useful idea.  So maybe
it's better to do it with a named local function instead:

  def makeButton(n):
  def button(number): print('button%d = %d' % (n, number))
  return button;

And now you can use code to make the list since the button number is now
data.

  buttonList = [makeButton(i) for i in range(1, 3)]

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

Re: Calling the source command from subprocess.popen to update the os.environ.

[Hongyi Zhao]

On Sun, 27 Mar 2016 13:24:05 +, Hongyi Zhao wrote:

> # replace env 
> os.environ.clear()

I find another method which can solve this issue, ie., changing the above 
code into the follows:

# ref : http://unix.stackexchange.com/questions/178522/unsetting-
environment-variable-with-an-empty-name
if "" in os.environ.data: del os.environ.data[""]
os.environ.clear()

Regards
-- 
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to make Python interpreter a little more strict?

[Nobody]

On Sat, 26 Mar 2016 23:30:30 +, John Pote wrote:

> So I have sympathy with the OP, I would expect the compiler to pick this
> up

Why? The code is valid, the compiler knows how to generate the
appropriate bytecode for it.

The compiler isn't "lint".

Reporting code which is actually invalid is fairly straightforward.
When the parser attempts to match the next token against a parse rule
and finds that nothing matches (e.g. the "fnc next" example), it just
needs to raise a SyntaxError. The point at which the exception needs to be
raised naturally exists in the code.

But to identify code which is perfectly valid yet is "probably" a mistake
first requires someone to identify such cases, then someone needs to start
adding the appropriate tests to the compiler to distinguish such code from
the rest.

> It would be all to easy to write a series of lines just calling
> functions and forget the () on one of them. Not fun programming. It's
> also a good reminder that the meaning of a keyword in language A is not
> necessarily the same in language B (ie 'next', Python)

"next" isn't a keyword, it's a built-in function. It's perfectly valid to
re-use that name for your own variables or functions.

> So on this last point is this behaviour of Python defined somewhere in
> the docs? 

What behaviour? Evaluating a name?

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

Re: List of Functions

[Erik]

Hi Richard,

On 27/03/16 20:38, Richard Riehle wrote:

I realize that this seems trivial to many experience Pythonistas.  But it might 
prove useful for those who are relative newcomers


Thanks for sharing your solution (people finding the original question 
because it happens to match their own may then find this follow-up).


However, please also read PEP8 -

https://www.python.org/dev/peps/pep-0008/


def button1(number):

print ('button1 = ', number)  ## define the buttons

def button2(number):

print ('button2 = ', number)

def button3(number):

print ('button3 = ', number)

buttonList = [button1, button2, button3]  ## create the list

buttonList [1] (25)  ## using positional association

button2 =  25

buttonList [0] (number = 78)  ## using named association

button1 = 78



The whitespace before the [] and () is what I'm referring you to PEP8 
about. Of course, you can do what you want - this is just a friendly 
nudge ;) That extra whitespace does make it a bit harder to grok if 
you're used to reading "typical" Python code.


BR, E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[BartC]

On 27/03/2016 22:55, Ned Batchelder wrote:

On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:

On 27/03/2016 18:19, Ned Batchelder wrote:

On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:



There would be a list of expression terms that can also form independent
statements. Not knowing Python, the list would comprise function calls
(ie. the function call is top node in the AST of the expression), and
docstrings.


It's a little frustrating to discuss language design when you claim not to
know Python.  Perhaps you could devote some off-list time to learning it? :)


Since the language is presumably available to anyone including
non-experts, why shouldn't someone who is only going to use a subset,
have an opinion on a troublesome part of the language?


It will be a partly-informed opinion.  If you are OK with that, I guess
I will have to be also.


One of Guido's principles in designing Python was to keep it simple,


For a simple language, there appear to be quite a few esoteric uses
being thought up for that feature!


Yes, it's impressive the things a simple design can accomplish.

In the end, I'm not sure what the goal of this discussion is.  We've
discussed something you don't like about Python.  We've explained as best
we can why the language is the way it is.  You still think it's a
deficiency.  What now?


Stalemate I guess.

Actually I'm not that bothered by this, but as someone else brought it 
up, I just wondered why Python was doing the same as C in allowing 
arbitrary expressions to be evaluated for no apparent reason. Now I know.


--
Bartc

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Ned Batchelder]

On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote:
> On 27/03/2016 18:19, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
> 
> >> There would be a list of expression terms that can also form independent
> >> statements. Not knowing Python, the list would comprise function calls
> >> (ie. the function call is top node in the AST of the expression), and
> >> docstrings.
> >
> > It's a little frustrating to discuss language design when you claim not to
> > know Python.  Perhaps you could devote some off-list time to learning it? :)
> 
> Since the language is presumably available to anyone including 
> non-experts, why shouldn't someone who is only going to use a subset, 
> have an opinion on a troublesome part of the language?

It will be a partly-informed opinion.  If you are OK with that, I guess
I will have to be also.  

> >>> One of Guido's principles in designing Python was to keep it simple,
> 
> For a simple language, there appear to be quite a few esoteric uses 
> being thought up for that feature!

Yes, it's impressive the things a simple design can accomplish.

In the end, I'm not sure what the goal of this discussion is.  We've
discussed something you don't like about Python.  We've explained as best
we can why the language is the way it is.  You still think it's a
deficiency.  What now?

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

Re: How to make Python interpreter a little more strict?

[Chris Angelico]

On Mon, Mar 28, 2016 at 7:49 AM, BartC  wrote:
> On 27/03/2016 21:32, Tim Chase wrote:
>>
>> On 2016-03-27 14:28, Steven D'Aprano wrote:
>
>
>>> In this case, the two lines "fnc" and "next" simply look up the
>>> function names, but without actually calling them. They're not
>>> quite "no-ops", since they can fail and raise NameError if the name
>>> doesn't exist, but otherwise they might as well be no-ops.
>>
>>
>> Which is actually useful.  I've got some 2.4 code that reads
>>
>>try:
>>  any
>>except NameError:
>>  def any(...):
>>...
>>
>> (with a similar block for all() )
>>
>> I don't want to call any() or all(), I simply want to test whether
>> they exist.
>
>
> But would it have been much of an imposition to have typed:
>
> try:
>   test = any
> except NameError:
>   def any(...):
> ...
>
> ? (Or any of the half dozen ways there must be to test the existence of a
> name.)

It shifts the uselessness to "why did you assign to that name?". While
that's not too bad (and nothing like as bad as a dummy function call),
it's generally reserved for the places where Python syntax mandates an
assignment:

for _ in range(4): next(iter) # discard the headers

If you're building a linter, I would expect "name assigned to and
never used" to be its own warning; but also, the try/except block
hints that this isn't useless. Generally, "dummy expressions" like
this are going to explicitly catch at least one exception that can be
raised only in that expression (ie a really small try block). That
pretty much counts as your language-level marker for conscious dummy
expression usage.

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Oscar Benjamin]

On 27 Mar 2016 23:11, "Ben Bacarisse"  wrote:
>
> Steven D'Aprano  writes:
>
> > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> >
> >> Steven D'Aprano  writes:
> >>> For example, would you consider that this isolated C code is
> >>> "meaningless"?
> >>> int i = n + 1;
> >>
> >> It's meaningful as long as n is in a certain range of values so there's
> >> no overflow.
> >>
> >>> But according to the standard, it's "meaningless", since it might
> >>> overflow, and signed int overflow is Undefined Behaviour.
> >>
> >> No it's not meaningless if it "might" overflow, it's meaningless if it
> >> -does- overflow,
> >
> > No! That's exactly wrong!
> >
> > Paul, thank you for inadvertently proving the point I am trying to get
> > across. People, even experienced C coders, simply don't understand what
the
> > C standard says and what C compilers can and will do.
> >
> > If the C compiler cannot prove that n is strictly less than MAXINT (or
is
> > that spelled INT_MAX?),
>
> (the latter)
>
> > the *entire program* (or at least the bits reachable from this line,
> > in both directions) is Undefined, and the compiler has no obligations
> > at all.
>
> If I understand you correctly, you are claiming that in this program
>
>   #include 
>
>   int main(int argc, char **argv)
>   {
>  int n = argc > 1 ? atoi(argv[1]) : 0;
>  int i = n + 1;  // not needed but used because it's the line in
question
>  printf("Hello world\n");
>   }
>
> everything after "int i = n + 1;" is undefined because the compiler
> can't prove that n is strictly less than INT_MAX.

Although Steve is incorrect to say that everything is undefined just
because the compiler can't prove that n != INT_MAX one thing that he is
right about is that undefined behaviour applies to the whole program. So if
the n+1 does lead to undefined behaviour (i.e. if n == INT_MAX) then the
behaviour is also undefined *before* that line. If we change the line to
INT_MAX+1 then a compiler is free to do whatever it likes with the *entire*
program.

In practice what this means is that an optimising compiler can see n+1 and
then optimise using the assumption that n!=INT_MAX (since there are *zero*
constraints on the behaviour of the *entire* program if that assumption is
broken). This optimisation could for example remove an if(n==INT_MAX) block
as dead code even if the check occurs *before* the line that involves n+1
which can be surprising. Of course if the check is used to conditionally
execute n+1 then the assumption cannot be applied by the optimiser so it's
still entirely possible to avoid this particular undefined behaviour.

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

Re: How to make Python interpreter a little more strict?

[BartC]

On 27/03/2016 21:32, Tim Chase wrote:

On 2016-03-27 14:28, Steven D'Aprano wrote:



In this case, the two lines "fnc" and "next" simply look up the
function names, but without actually calling them. They're not
quite "no-ops", since they can fail and raise NameError if the name
doesn't exist, but otherwise they might as well be no-ops.


Which is actually useful.  I've got some 2.4 code that reads

   try:
 any
   except NameError:
 def any(...):
   ...

(with a similar block for all() )

I don't want to call any() or all(), I simply want to test whether
they exist.


But would it have been much of an imposition to have typed:

try:
  test = any
except NameError:
  def any(...):
...

? (Or any of the half dozen ways there must be to test the existence of 
a name.)


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

Re: How to make Python interpreter a little more strict?

[Tim Chase]

On 2016-03-27 14:28, Steven D'Aprano wrote:
> > So intrigued by this question I tried the following
> > def fnc( n ):
> >  print "fnc called with parameter '%d'" % n
> >  return n
> > 
> > for i in range(0,5):
> >  if i%2 == 0:
> >  fnc
> >  next
> >  print i
> > 
> > and got the same result as the OP  
> 
> In this case, the two lines "fnc" and "next" simply look up the
> function names, but without actually calling them. They're not
> quite "no-ops", since they can fail and raise NameError if the name
> doesn't exist, but otherwise they might as well be no-ops.

Which is actually useful.  I've got some 2.4 code that reads

  try:
any
  except NameError:
def any(...):
  ...

(with a similar block for all() )

I don't want to call any() or all(), I simply want to test whether
they exist.

-tkc



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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[BartC]

On 27/03/2016 18:19, Ned Batchelder wrote:

On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:



There would be a list of expression terms that can also form independent
statements. Not knowing Python, the list would comprise function calls
(ie. the function call is top node in the AST of the expression), and
docstrings.


It's a little frustrating to discuss language design when you claim not to
know Python.  Perhaps you could devote some off-list time to learning it? :)


Since the language is presumably available to anyone including 
non-experts, why shouldn't someone who is only going to use a subset, 
have an opinion on a troublesome part of the language?



One of Guido's principles in designing Python was to keep it simple,


For a simple language, there appear to be quite a few esoteric uses 
being thought up for that feature!


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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Ben Bacarisse]

Steven D'Aprano  writes:

> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
>> Steven D'Aprano  writes:
>>> For example, would you consider that this isolated C code is
>>> "meaningless"?
>>> int i = n + 1;
>> 
>> It's meaningful as long as n is in a certain range of values so there's
>> no overflow.
>> 
>>> But according to the standard, it's "meaningless", since it might
>>> overflow, and signed int overflow is Undefined Behaviour.
>> 
>> No it's not meaningless if it "might" overflow, it's meaningless if it
>> -does- overflow, 
>
> No! That's exactly wrong!
>
> Paul, thank you for inadvertently proving the point I am trying to get
> across. People, even experienced C coders, simply don't understand what the
> C standard says and what C compilers can and will do.
>
> If the C compiler cannot prove that n is strictly less than MAXINT (or is
> that spelled INT_MAX?),

(the latter)

> the *entire program* (or at least the bits reachable from this line,
> in both directions) is Undefined, and the compiler has no obligations
> at all.

If I understand you correctly, you are claiming that in this program

  #include 

  int main(int argc, char **argv)
  {
 int n = argc > 1 ? atoi(argv[1]) : 0;
 int i = n + 1;  // not needed but used because it's the line in question
 printf("Hello world\n");
  }

everything after "int i = n + 1;" is undefined because the compiler
can't prove that n is strictly less than INT_MAX.  (In fact atoi
exhibits undefined behaviour in some cases which the compiler can't
prove don't apply here either, so the trouble could happen even
earlier.)

Given that the only observable behaviour is the printf call, would the
fact that the program is undefined by that point mean that a compiler
could generate code equivalent to

  #include 

  int main(void) { puts("You loose!\n"); }

and still be conforming according to the language standard?  (Obviously
this is a rather mild option given that anything is permitted.)  That
*seems* to be what you are saying, but it's not backed up by what the C
people I know say.  In particular


> But don't believe me. What do I know about C, I don't even know whether to
> spell the biggest int MAXINT or INT_MAX or MAX_INT. Instead, believe these
> guys:
>
> http://blog.regehr.org/archives/213
> http://blog.regehr.org/archives/226
> http://blog.regehr.org/archives/232
>
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

don't seem to be saying that.  Whilst I've not yet read them all, they
seem be unexceptional explanations of UB in C (by which I mean they
accord with what I understand it to be!) and I don't see how they
confirm what I think you are saying.


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

List of Functions

[Richard Riehle]

Several months ago, I posted a question regarding how to create a list of 
functions.  I quickly solved the problem on my own, but I am just now getting 
around to sharing my solution.  It was actually quite simple, and also quite 
useful for the problem I had at hand.  Below is an example of one way to do 
this.  There are actually some other solutions.

This solution is based on the fact that Python functions are first-class 
objects, and therefore enable one to emulate functional programming.   

Consider that we might need a list of buttons, each of which can behave 
differently based on a parameter list.   First, we define three button 
functions with a parameter.  Then, we create a list of those functions. 

The tricky part is how we formulate the actual function call.   I demonstrate 
this in the last two lines of the code below.   

I realize that this seems trivial to many experience Pythonistas.  But it might 
prove useful for those who are relative newcomers to the language.  In any 
case, I hope someone can find it helpful.  

>>> def button1(number):
print ('button1 = ', number)  ## define the buttons
>>> def button2(number):
print ('button2 = ', number)
>>> def button3(number):
print ('button3 = ', number)
>>> buttonList = [button1, button2, button3]  ## create the list
>>>
>>> buttonList [1] (25)  ## using positional association
button2 =  25
>>>buttonList [0] (number = 78)  ## using named association
button1 = 78
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Mark Lawrence]

On 27/03/2016 19:01, Marco S. via Python-list wrote:


Mark Lawrence wrote:


I cannot see this happening unless you provide a patch on the bug
tracker.  However I suspect you can get the same thing by subclassing
dict.  Why don't you try it and let us know how you get on?


The problem with a vdict is that I should also create by zero a new
interface (ABC), since MutableMapping have an incompatible contract.
And to be much more useful I should code it inc C, and my C skills are
not so magnificent. Furthermore I would try to create a new sequence
interface that inherit from the vdict interface. More briefly, I need
much free time. But I suppose I can start with something quick and
dirty.



Why do you need a new interace if all you're trying to do is create a
vdict class that has "iter(d) == iter(d.values()), and should also
have a count() method, like sequence types"?

I don't understand why you think you need C skills.  E.g. 
SortedContainers https://pypi.python.org/pypi/sortedcontainers "is an 
Apache2 licensed containers library, written in pure-Python, and fast as 
C-extensions."


I think your quick and dirty might well turn into something useful for 
your application.


--
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: Help with python script for NMR

[mohamadmaaz5]

On Sunday, March 27, 2016 at 7:40:06 PM UTC+2, Peter Otten wrote:
> mohamadma...@gmail.com wrote:
> 
> > On Sunday, March 27, 2016 at 4:50:01 PM UTC+2, Joel Goldstick wrote:
> >> On Sun, Mar 27, 2016 at 10:38 AM,  wrote:
> >> 
> >> > Hello there,
> >> > I found a python script in a scientific article that enables a simple
> >> > calculation on an NMR spectrum.
> >> > I have no experience in programming and i would appreciate it if i can
> >> > communicate with someone who can write this script and send it to me by
> >> > mail in py format. It's a short script but i keep making alot of
> >> > mistaken and it fails every time.
> >> > Anyone's interested in helping me ?
> >> > Thanks
> >> > --
> >> > https://mail.python.org/mailman/listinfo/python-list
> >> >
> >> 
> >> copy the code here.  You will get help, but people don't generally write
> >> programs for others here
> >> 
> >> --
> >> Joel Goldstick
> >> http://joelgoldstick.com/ 
> >> http://cc-baseballstats.info/
> > 
> > this is the script. the thing is that i have zero experience in writing
> > and i cant find the error. all i need is to embed this script to perfome a
> > relatively simple calculation on a spectra. hope anyone can help. thanks
> > 
> > #! /usr /bin/envpython
> > #encoding:utf- 8
> > i m p o r tnmrtec . nmrNotebook . c o n t r o l l e r . C o n t r o l l e
> > r as Cont i m p o r tnmrtec . u t i l as u t i l
> > i m p o r tnmrtec . nmrNotebook . model . common .nmrCommon as nmrcom
> > c l a s sBarycentre :
> 
> If you want to turn Annex B of www.theses.fr/2014STRAJ015.pdf into runnable 
> Python please note
> 
> """
> Created by Marie-Aude Coutouly , Justine Vieville, Matthieu ...
> ...Tanty and Marc-Andre Delsuc on 2010-11-04
> Copyright ( c ) 2010 NMRTEC and IGBMC. All rights Reserved .
> 
> 
> If you didn't already contact the author(s) you should try that first -- 
> perhaps they can provide a copy of the original script.

already sent a request and waiting, thank you
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion: make sequence and map interfaces more similar

[Marco S. via Python-list]

Steven D'Aprano wrote:

> The point you might have missed is that treating lists as if they were
> mappings violates at least one critical property of mappings: that the
> relationship between keys and values are stable.


This is true for immutable maps, but for mutable ones, you can simply do

map[key] = new_value

You can easily create a new class that extend dict and add to it a
method that emulated the insert method of lists. It will definitively
not break any contract, if your contract is "sequences are maps with
ordered integer keys that starts from zero and have no gaps".

Mark Lawrence wrote:

> I cannot see this happening unless you provide a patch on the bug
> tracker.  However I suspect you can get the same thing by subclassing
> dict.  Why don't you try it and let us know how you get on?

The problem with a vdict is that I should also create by zero a new
interface (ABC), since MutableMapping have an incompatible contract.
And to be much more useful I should code it inc C, and my C skills are
not so magnificent. Furthermore I would try to create a new sequence
interface that inherit from the vdict interface. More briefly, I need
much free time. But I suppose I can start with something quick and
dirty.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help with python script for NMR

[Peter Otten]

mohamadma...@gmail.com wrote:

> On Sunday, March 27, 2016 at 4:50:01 PM UTC+2, Joel Goldstick wrote:
>> On Sun, Mar 27, 2016 at 10:38 AM,  wrote:
>> 
>> > Hello there,
>> > I found a python script in a scientific article that enables a simple
>> > calculation on an NMR spectrum.
>> > I have no experience in programming and i would appreciate it if i can
>> > communicate with someone who can write this script and send it to me by
>> > mail in py format. It's a short script but i keep making alot of
>> > mistaken and it fails every time.
>> > Anyone's interested in helping me ?
>> > Thanks
>> > --
>> > https://mail.python.org/mailman/listinfo/python-list
>> >
>> 
>> copy the code here.  You will get help, but people don't generally write
>> programs for others here
>> 
>> --
>> Joel Goldstick
>> http://joelgoldstick.com/ 
>> http://cc-baseballstats.info/
> 
> this is the script. the thing is that i have zero experience in writing
> and i cant find the error. all i need is to embed this script to perfome a
> relatively simple calculation on a spectra. hope anyone can help. thanks
> 
> #! /usr /bin/envpython
> #encoding:utf- 8
> i m p o r tnmrtec . nmrNotebook . c o n t r o l l e r . C o n t r o l l e
> r as Cont i m p o r tnmrtec . u t i l as u t i l
> i m p o r tnmrtec . nmrNotebook . model . common .nmrCommon as nmrcom
> c l a s sBarycentre :

If you want to turn Annex B of www.theses.fr/2014STRAJ015.pdf into runnable 
Python please note

"""
Created by Marie−Aude Coutouly , Justine Vieville, Matthieu ...
...Tanty and Marc−Andre Delsuc on 2010−11−04
Copyright ( c ) 2010 NMRTEC and IGBMC. All rights Reserved .


If you didn't already contact the author(s) you should try that first -- 
perhaps they can provide a copy of the original script.

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Ned Batchelder]

On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote:
> On 27/03/2016 16:48, Ned Batchelder wrote:
> > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> >> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
> 
> >> Well, that could be done in Python (not so usefully because you can't
> >> take account of such info until a call is attempted), but that's not
> >> what I'm talking about, which is simply allowing:
> >>
> >> fn(...)
> >>
> >> whether fn has an explicit return or not, and not allowing:
> >>
> >> fn # and other kinds of expression
> >>
> >> unless some keyword is used. (I've no idea what that might be; all the
> >> best ones are taken. But I've already said a keyword can be emulated via
> >> a dummy function call.)
> >
> > Python *could* have made it an error to have a useless expression as a
> > statement.  It would prevent certain kinds of errors.  But it would also
> > complicate the language.  How do we decide what is a "useless expression"?
> 
> Probably one that would raise eyebrows when used as an expression. Such 
> as 'f()+1', even though f() might have useful side-effects.
> 
> > As we've seen this might be an expression with a side-effect:
> >
> >  foo.bar
> >
> > though it would be unusual.  Should it be forbidden?
> 
> No. The language can require a prefix, or the coder can put it into a 
> legal form (pass it to a dummy function for example).

Yes, I misspoke, by "forbidden" of course I meant, "forbidden as statement
on its own," which is what we are talking about.

> 
> > And how do we make docstrings, which are simply string literals as
> > statements?  Or do we allow those?  Perhaps we only allow those if they
> > are the first statement in a module, class, or function?  How complicated
> > do we want these criteria to become?
> 
> There would be a list of expression terms that can also form independent 
> statements. Not knowing Python, the list would comprise function calls 
> (ie. the function call is top node in the AST of the expression), and 
> docstrings.

It's a little frustrating to discuss language design when you claim not to
know Python.  Perhaps you could devote some off-list time to learning it? :)

> The suggestion has also been made only bare names should be disallowed, 
> which would probably trap most of the errors it causes, early on.

As Terry pointed out, the interactive interpreter would then need different
rules, since of course using bare names there is essential.  The interactive
interpreter is already a bit different, but you can see this is starting
to snowball.

> 
> > One of Guido's principles in designing Python was to keep it simple,
> > even where that might mean people could make errors with it.  This part
> > of the language is no different: any expression can be a statement.
> 
> Yeah, but even simpler would be that any statement can also be an 
> expression! He didn't go that far though.

Nope, he didn't.  As I said, it's a complex set of design considerations.
No single factor is going to be pushed to the maximum.  I'm not sure what
point you are making.

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

Re: Help with python script for NMR

[Wildman via Python-list]

On Sun, 27 Mar 2016 09:40:57 -0700, mohamadmaaz5 wrote:

> On Sunday, March 27, 2016 at 6:27:59 PM UTC+2, Wildman wrote:
>> On Sun, 27 Mar 2016 09:15:39 -0700, mohamadmaaz5 wrote:
>> 
>> > On Sunday, March 27, 2016 at 6:07:43 PM UTC+2, Wildman wrote:
>> >> On Sun, 27 Mar 2016 08:13:49 -0700, mohamadmaaz5 wrote:
>> >> 
>> >> >> > Hello there,
>> >> >> > I found a python script
>> >> 
>> >> The formatting of the script is all wrong.  There are many
>> >> spaces that should not be there and no indentations.  It
>> >> could take a long time to figure it out.  It could be just
>> >> a copy/paste problem on the part of the website.  Do you
>> >> have the link to the original article?
>> >> 
>> >> -- 
>> >>  GNU/Linux user #557453
>> >> The cow died so I don't need your bull!
>> > 
>> > yeah this is exactly the problem, and i eliminated the spaces but still 
>> > failed. this is the article (script in supporting info):
>> > http://www.sciencedirect.com/science/article/pii/S1090780711002072
>> 
>> I am not finding a link to the script.  The website says that I
>> have "Guest" access.  Does this mean I have to pay to see the
>> script?
>> 
>> -- 
>>  GNU/Linux user #557453
>> The cow died so I don't need your bull!
> 
> can you please give me your email to send you the article ?

The email address in my header is valid.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[BartC]

On 27/03/2016 16:48, Ned Batchelder wrote:

On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:

On 27/03/2016 14:47, Dennis Lee Bieber wrote:



Well, that could be done in Python (not so usefully because you can't
take account of such info until a call is attempted), but that's not
what I'm talking about, which is simply allowing:

fn(...)

whether fn has an explicit return or not, and not allowing:

fn # and other kinds of expression

unless some keyword is used. (I've no idea what that might be; all the
best ones are taken. But I've already said a keyword can be emulated via
a dummy function call.)


Python *could* have made it an error to have a useless expression as a
statement.  It would prevent certain kinds of errors.  But it would also
complicate the language.  How do we decide what is a "useless expression"?


Probably one that would raise eyebrows when used as an expression. Such 
as 'f()+1', even though f() might have useful side-effects.



As we've seen this might be an expression with a side-effect:

 foo.bar

though it would be unusual.  Should it be forbidden?


No. The language can require a prefix, or the coder can put it into a 
legal form (pass it to a dummy function for example).



And how do we make docstrings, which are simply string literals as
statements?  Or do we allow those?  Perhaps we only allow those if they
are the first statement in a module, class, or function?  How complicated
do we want these criteria to become?


There would be a list of expression terms that can also form independent 
statements. Not knowing Python, the list would comprise function calls 
(ie. the function call is top node in the AST of the expression), and 
docstrings.


(In other languages it might also include assignments and increments.)

The suggestion has also been made only bare names should be disallowed, 
which would probably trap most of the errors it causes, early on.



One of Guido's principles in designing Python was to keep it simple,
even where that might mean people could make errors with it.  This part
of the language is no different: any expression can be a statement.


Yeah, but even simpler would be that any statement can also be an 
expression! He didn't go that far though.


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

Re: Help with python script for NMR

[mohamadmaaz5]

On Sunday, March 27, 2016 at 6:27:59 PM UTC+2, Wildman wrote:
> On Sun, 27 Mar 2016 09:15:39 -0700, mohamadmaaz5 wrote:
> 
> > On Sunday, March 27, 2016 at 6:07:43 PM UTC+2, Wildman wrote:
> >> On Sun, 27 Mar 2016 08:13:49 -0700, mohamadmaaz5 wrote:
> >> 
> >> >> > Hello there,
> >> >> > I found a python script
> >> 
> >> The formatting of the script is all wrong.  There are many
> >> spaces that should not be there and no indentations.  It
> >> could take a long time to figure it out.  It could be just
> >> a copy/paste problem on the part of the website.  Do you
> >> have the link to the original article?
> >> 
> >> -- 
> >>  GNU/Linux user #557453
> >> The cow died so I don't need your bull!
> > 
> > yeah this is exactly the problem, and i eliminated the spaces but still 
> > failed. this is the article (script in supporting info):
> > http://www.sciencedirect.com/science/article/pii/S1090780711002072
> 
> I am not finding a link to the script.  The website says that I
> have "Guest" access.  Does this mean I have to pay to see the
> script?
> 
> -- 
>  GNU/Linux user #557453
> The cow died so I don't need your bull!

can you please give me your email to send you the article ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Terry Reedy]

On 3/27/2016 11:48 AM, Ned Batchelder wrote:

On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:



whether fn has an explicit return or not, and not allowing:

fn # and other kinds of expression

unless some keyword is used.


Python *could* have made it an error to have a useless expression as a
statement.


In interactive mode, which is an essential part of Python, expression 
statements print the value of the expression.  Thus no expression is 
useless.


So Bart is proposing to either disable an extremely useful feature or 
split Python into two slightly different dialects.  I think both are bad 
ideas.


--
Terry Jan Reedy

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

Re: Help with python script for NMR

[Peter Pearson]

On Sun, 27 Mar 2016 08:13:49 -0700 (PDT), mohamadma...@gmail.com wrote:
> On Sunday, March 27, 2016 at 4:50:01 PM UTC+2, Joel Goldstick wrote:
>> On Sun, Mar 27, 2016 at 10:38 AM,  wrote:
>> 
>> > Hello there,
>> > I found a python script in a scientific article that enables a simple
>> > calculation on an NMR spectrum.
>> > I have no experience in programming and i would appreciate it if i can
>> > communicate with someone who can write this script and send it to me by
>> > mail in py format. It's a short script but i keep making alot of mistaken
>> > and it fails every time.
>> > Anyone's interested in helping me ?
[snip]
>> 
>> copy the code here.  You will get help, but people don't generally write
>> programs for others here
>> 
>> -- 
>> Joel Goldstick
>> http://joelgoldstick.com/ 
>> http://cc-baseballstats.info/
>
> this is the script. the thing is that i have zero experience in
> writing and i cant find the error. all i need is to embed this script
> to perfome a relatively simple calculation on a spectra. hope anyone
> can help. thanks
>
> #! /usr /bin/envpython
> #encoding:utf- 8
> i m p o r tnmrtec . nmrNotebook . c o n t r o l l e r . C o n t r o [snip]
> i m p o r tnmrtec . u t i l as u t i l
> i m p o r tnmrtec . nmrNotebook . model . common .nmrCommon as nmrcom
> c l a s sBarycentre :
> """
> computesthebarycenterofeach
> definedr e c t a n g l eanddeducesthe
> p o l y d i s p e r s i t yindexofthes o l u t i o n
[snip]

It appears that spaces have been inserted and deleted at many points
in this code, and anybody deciding to help with your project will start
with the task of guessing where spaces need to be inserted and deleted
in order to restore the original code.  Since indentation is important
in Python, this will not be a trivial problem.  If the scientific article
that presented this script shows correct spacing, you should take your
best shot at correcting the spacing.

Also, it appears that several lines begin "import nmrtec", indicating
that this script requires a module named nmrtec.

-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help with python script for NMR

[Wildman via Python-list]

On Sun, 27 Mar 2016 09:15:39 -0700, mohamadmaaz5 wrote:

> On Sunday, March 27, 2016 at 6:07:43 PM UTC+2, Wildman wrote:
>> On Sun, 27 Mar 2016 08:13:49 -0700, mohamadmaaz5 wrote:
>> 
>> >> > Hello there,
>> >> > I found a python script
>> 
>> The formatting of the script is all wrong.  There are many
>> spaces that should not be there and no indentations.  It
>> could take a long time to figure it out.  It could be just
>> a copy/paste problem on the part of the website.  Do you
>> have the link to the original article?
>> 
>> -- 
>>  GNU/Linux user #557453
>> The cow died so I don't need your bull!
> 
> yeah this is exactly the problem, and i eliminated the spaces but still 
> failed. this is the article (script in supporting info):
> http://www.sciencedirect.com/science/article/pii/S1090780711002072

I am not finding a link to the script.  The website says that I
have "Guest" access.  Does this mean I have to pay to see the
script?

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help with python script for NMR

[mohamadmaaz5]

On Sunday, March 27, 2016 at 6:07:43 PM UTC+2, Wildman wrote:
> On Sun, 27 Mar 2016 08:13:49 -0700, mohamadmaaz5 wrote:
> 
> >> > Hello there,
> >> > I found a python script
> 
> The formatting of the script is all wrong.  There are many
> spaces that should not be there and no indentations.  It
> could take a long time to figure it out.  It could be just
> a copy/paste problem on the part of the website.  Do you
> have the link to the original article?
> 
> -- 
>  GNU/Linux user #557453
> The cow died so I don't need your bull!

yeah this is exactly the problem, and i eliminated the spaces but still failed. 
this is the article (script in supporting info):
http://www.sciencedirect.com/science/article/pii/S1090780711002072

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

Re: Why lambda in loop requires default?

[Terry Reedy]

On 3/26/2016 9:46 PM, gvim wrote:

Given that Python, like Ruby, is an object-oriented language why doesn't
this:

def m():
   a = []
   for i in range(3): a.append(lambda: i)
   return a

def echo_i: return i



b = m()
for n in range(3): print(b[n]())  # =>  2  2  2


)  # =>  2  2  2


... work the same as this in Ruby:

def m
   a = []
   (0..2).each {|i| a << ->(){i}}
   a
end

aa = m
(0..2).each {|n| puts aa[n].()}  # =>  0  1  2


Since Python came first, and Ruby was partly inspired by and derived 
from Python, perhaps you should ask Ruby folk why it does not work the 
same as Python.  (Because Matz wanted it different.)



lambda i=i: i

... is needed to make it work in Python. Just wondered why?


Your Python def m is essentially equivalent to

def m():
  def echo_i(): return i
  i = 2
  return [echo_i]*3

--
Terry Jan Reedy

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

Re: Help with python script for NMR

[Wildman via Python-list]

On Sun, 27 Mar 2016 08:13:49 -0700, mohamadmaaz5 wrote:

>> > Hello there,
>> > I found a python script

The formatting of the script is all wrong.  There are many
spaces that should not be there and no indentations.  It
could take a long time to figure it out.  It could be just
a copy/paste problem on the part of the website.  Do you
have the link to the original article?

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Ned Batchelder]

On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
> > On Sun, 27 Mar 2016 12:31:26 +0100, BartC  declaimed the
> > following:
> >
> >> On 27/03/2016 07:34, Paul Rubin wrote:
> >>> BartC  writes:
> But my suggestion was to have required a keyword in front of
>  such expressions.
> >>>
> >>> Should there be a keyword in front of a line containing "sqrt(x)" ?
> >>> What about "launch(missiles)" ?
> >>
> >> They both look like function calls. Function calls are *very* commonly
> >> used as standalone expressions.
> >>
> >> You /could/ stipulate that they be written:
> >>
> >>call launch(missiles)# like Fortran iirc
> >>
> > Except that FORTRAN also explicitly defines them as
> >
> > subroutine xxx()
> > vs
> > return-type function yyy()
> >
> > and will generate a compile error if you "call" the latter, or put the
> > former in-line of an expression
> >
> > This would be the equivalent of removing "def" from Python, and adding
> > two new keywords: "sub" and "fun"; modifying the behavior so that "fun"s
> > must have an explicit return statement (preferably with an explicit return
> > value), whereas "sub"s have no return and just ... end...
> 
> Well, that could be done in Python (not so usefully because you can't 
> take account of such info until a call is attempted), but that's not 
> what I'm talking about, which is simply allowing:
> 
>fn(...)
> 
> whether fn has an explicit return or not, and not allowing:
> 
>fn # and other kinds of expression
> 
> unless some keyword is used. (I've no idea what that might be; all the 
> best ones are taken. But I've already said a keyword can be emulated via 
> a dummy function call.)

Python *could* have made it an error to have a useless expression as a
statement.  It would prevent certain kinds of errors.  But it would also
complicate the language.  How do we decide what is a "useless expression"?

As we've seen this might be an expression with a side-effect:

foo.bar

though it would be unusual.  Should it be forbidden?

And how do we make docstrings, which are simply string literals as
statements?  Or do we allow those?  Perhaps we only allow those if they
are the first statement in a module, class, or function?  How complicated
do we want these criteria to become?

One of Guido's principles in designing Python was to keep it simple,
even where that might mean people could make errors with it.  This part
of the language is no different: any expression can be a statement.

Any real language is designed with a number of competing factors in mind.
It isn't a simple matter.  Usually the answer to, "why was it done this
way?" is, "Because the designer had a different set of criteria, ordered
differently, than you do."  Python cares about preventing errors.  It
also cares about simplicity of design.

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

Re: help with program

[Terry Reedy]

On 3/27/2016 10:18 AM, Bob Gailer wrote:

The problem with putting input at the end of a program is: if the program
raises an exception you won't see it.


What you are saying is that putting input() at the end of a program (or 
before any exit point) is insufficient for keeping a window alive if the 
program has a bug that causes an exception.  If that is considered 
possible, wrap the entire code in try-except and print or log the 
exception before using input to keep the window alive.  During 
development, it is easier to just run the program in a persistent 
environment, whether console or IDE such as IDLE.


--
Terry Jan Reedy

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

Re: Why lambda in loop requires default?

[Ned Batchelder]

On Sunday, March 27, 2016 at 9:55:16 AM UTC-4, g vim wrote:
> Given that Python, like Ruby, is an object-oriented language 

It turns out that "object-oriented" means very little, and lots
of languages that are object-oriented will behave differently
from each other, even where object behavior is concerned.

> why doesn't 
> this:
> 
> def m():
>a = []
>for i in range(3): a.append(lambda: i)
>return a
> 
> b = m()
> for n in range(3): print(b[n]())  # =>  2  2  2
> 
> ... work the same as this in Ruby:
> 
> def m
>a = []
>(0..2).each {|i| a << ->(){i}}
>a
> end
> 
> aa = m
> (0..2).each {|n| puts aa[n].()}  # =>  0  1  2
> 

Like Jussi, I don't know Ruby enough to tell you why Ruby *does*
work as you want, but I can help explain why Python doesn't work
as you want.

When you write "lambda: i", you are creating a closure, because
i is a name from outside the lambda.  In that case, the function
you create with the lambda refers to the variable i, not to the
value i had when you made the lambda.

Later, when you run the function, it will use the current value
of the variable i.  In this case, you have three functions, all
of which refer to the same i, and when you run them all, i is 2,
so they all produce 2.

> 
> lambda i=i: i
> 
> ... is needed to make it work in Python. Just wondered why?

Here you are using the local i as the default value for the
function parameter i.  Function parameter defaults are evaluated
when the function is defined, and the value is stored as part of
the function.  So all three of your functions store a different
value as the default for i.  When the functions are called, they
each use their distinct value as the default for the missing
argument, and they produce 0, 1, 2.

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

Re: Why lambda in loop requires default?

[Jussi Piitulainen]

gvim writes:

> Given that Python, like Ruby, is an object-oriented language why
> doesn't this:
>
> def m():
>   a = []
>   for i in range(3): a.append(lambda: i)
>   return a
>
> b = m()
> for n in range(3): print(b[n]())  # =>  2  2  2
>
> ... work the same as this in Ruby:
>
> def m
>   a = []
>   (0..2).each {|i| a << ->(){i}}
>   a
> end
>
> aa = m
> (0..2).each {|n| puts aa[n].()}  # =>  0  1  2

No, I'm not taking this to private correspondence, and *I'm* not going
to talk about why Python "couldn't" do certain things differently when
other languages apparently can.

I don't know Ruby. It looks gibberish to me, but my *guess* is that the
following way to make Python give you what you want is not "fiddling" at
all but the exact *same* thing that Ruby makes you do.

fs = [ (lambda i: (lambda : i))(i) for i in range(3) ]
print([ f() for f in fs ]) # => [0, 1, 2]

The following is the same as above. I find it preferable.

fs = [ (lambda k: (lambda : k))(i) for i in range(3) ]
print([ f() for f in fs ]) # => [0, 1, 2]

And the following may be even more same as your Ruby thing.

fs = list(map(lambda k: (lambda : k), range(3)))
print([ f() for f in fs ]) # => [0, 1, 2]

So it's not at all like Python can't do this at all.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help with python script for NMR

[mohamadmaaz5]

On Sunday, March 27, 2016 at 4:50:01 PM UTC+2, Joel Goldstick wrote:
> On Sun, Mar 27, 2016 at 10:38 AM,  wrote:
> 
> > Hello there,
> > I found a python script in a scientific article that enables a simple
> > calculation on an NMR spectrum.
> > I have no experience in programming and i would appreciate it if i can
> > communicate with someone who can write this script and send it to me by
> > mail in py format. It's a short script but i keep making alot of mistaken
> > and it fails every time.
> > Anyone's interested in helping me ?
> > Thanks
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> 
> copy the code here.  You will get help, but people don't generally write
> programs for others here
> 
> -- 
> Joel Goldstick
> http://joelgoldstick.com/ 
> http://cc-baseballstats.info/

this is the script. the thing is that i have zero experience in writing and i 
cant find the error. all i need is to embed this script to perfome a relatively 
simple calculation on a spectra. hope anyone can help. thanks

#! /usr /bin/envpython
#encoding:utf- 8
i m p o r tnmrtec . nmrNotebook . c o n t r o l l e r . C o n t r o l l e r as 
Cont
i m p o r tnmrtec . u t i l as u t i l
i m p o r tnmrtec . nmrNotebook . model . common .nmrCommon as nmrcom
c l a s sBarycentre :
"""
computesthebarycenterofeach
definedr e c t a n g l eanddeducesthe
p o l y d i s p e r s i t yindexofthes o l u t i o n
"""
d e fi n i t( s e l f ) :
"""
i n i t i a l i z e sandgetthei n t e g r a t i o ncoo rdin ates
"""
df =1.86#tobechangedf o reachtypeof...
... molecule
f r o mNNBlibimportDialogText , l i s t O f R e c t a n g l e s
s e l f . d a t a = NNB . l o a d C u r r e n t D a t a ( )
i f( getdim () != 2 ) :
s e l f . die (" Tobeappliedon2Donly" )
i flen ( listOfRectangles () ) == 1 :
s e l f . die (" Youmustaddarectangletodefineazoomregion. " )
i flen ( listOfRectangles () )>2 :
s e l f . die (" expectedtwozoomregion. %dzoomregionsweredefined. " % ...
...len ( listOfRectangles () ) )
f o riin[ 0 , 1 ] :
indexRect = listOfRectangles () [ i ]
dim (2)
s e l f . F1Left = int ( indexRect [ 0 ] )
s e l f . F1Right = int ( indexRect [ 2 ] )
s e l f . F2Left = int ( indexRect [ 1 ] )
s e l f . F2Right = int ( indexRect [ 3 ] )
i fi==0 :
b = s e l f . pointToDamping ( s e l f . barycenter () )
b = b* *(- df )
else:
a = s e l f . pointToDamping ( s e l f . barycenter () )
a = a * *(- df )
ip=a/b
i fip<1.0:
ip= 1/ ip
r e s u l t=" p o l y d i s p e r s i t yindex: %s" %ip
DialogText (" Resultat" , r e s u l t )
#---
defpointToDamping ( s e l f , value ) :
" " "
p o i n t T o D a m p i n gc o n v e r t sp o i n t su n i t si n t od i f f u 
s i o nu n i t s
"""
c = Cont . getCurrentControllerDeDocument ( )
f o l d = c . getCurrentNMRFolder ( )
nsa = f o l d . getNNBNMRSpectrum ( ) . getAxisF ( 1 )
p r i n tvalue
newdamping = u t i l . NMRUnitToolKit . pointToUnit (nmrcom . NMRUnit . ...
...UNITDAMPING, nsa , value )
r e t u r nnewdamping
#---
d e fbarycenter ( s e l f ) :
"""
r e a l i z ethei n t e g r a t i o noverthei n t e g r a t i o nzones 
(obtainedati n i t i a l i z a t i o n)
"""
#i n i t i a l i s a t i o ndud a t a b u f f e razero
dim ( 1 )
zero ( )
put (" data" )
#onmetl apremierecolonne
dim ( 2 )
c o l ( i n t ( s e l f . F2Left ) )
dim ( 1 )
put (" data" )
f o rcolumninrange ( s e l f . F2Left +1, s e l f . F2Right +1) :
dim ( 2 )
c o l ( i n t ( column ) )
dim ( 1 )
a d d d a t a ( )
p u t (" data" )
dim(1)
get (" data" )
m=0
n=0
f o riinrange ( s e l f . F1Left , s e l f . F1Right+1) :
m += float ( val1d ( i ) )*i
n += float ( val1d ( i ) )
b = m/n
returnb
#thenexecute
Barycentre ()
i fname==" main" :
try:
Barycentre ()
except:
fromNNBlibimportalert , formatExceptionInfo
try:
alert ( formatExceptionInfo () )
except:
raise" shouldneverhappen"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling the source command from subprocess.popen to update the os.environ.

[Chris Angelico]

On Mon, Mar 28, 2016 at 12:24 AM, Hongyi Zhao  wrote:
> # replace env
> os.environ.clear()
> os.environ.update(line.partition('=')[::2] for line in output.split('\0'))
>
> Traceback (most recent call last):
>   File "/home/werner/anaconda2/lib/python2.7/site-packages/IPython/core/
> interactiveshell.py", line 3066, in run_code
> exec(code_obj, self.user_global_ns, self.user_ns)
>   File "", line 10, in 
> os.environ.clear()
>   File "/home/werner/anaconda2/lib/python2.7/os.py", line 501, in clear
> unsetenv(key)
> OSError: [Errno 22] Invalid argument
>
> If I don't use the `os.environ.clear()' code line, it will work smoothly.

Do you need to clear the environment first? Anything that's been
overwritten will replace stuff in os.environ, so the only reason to
clear it would be if you expect your env script to unset things. Is
that the case?

I'm not sure why the clear is a problem. Here's how I'd start debugging it:

for var in os.environ:
try: del os.environ[var]
except OSError: print(var)

Two possibilities: Either that raises OSError errno 22, same as
clear() does; or it doesn't. If it doesn't, you should have a clear
env, and all should be working (if a little odd) - and then you can
look into the possible bug with clear(). But more likely it will, and
then you'll be able to see exactly which key triggered the error.
Check out what that key is; maybe there's some kind of special
environment variable that can't be cleared??

Worst case, you can always do this "clear whatever you can", and then
do your environ.update(). Assuming you never need to clear one of the
unclearables, this'll give you the same env update as sourcing the
script did.

And worst worst case, you could probably exec to bash, source the
script, and exec back into Python. That should properly update the
environment, but it's a somewhat hamfisted way to go about it :)

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

Re: Help with python script for NMR

[Joel Goldstick]

On Sun, Mar 27, 2016 at 10:38 AM,  wrote:

> Hello there,
> I found a python script in a scientific article that enables a simple
> calculation on an NMR spectrum.
> I have no experience in programming and i would appreciate it if i can
> communicate with someone who can write this script and send it to me by
> mail in py format. It's a short script but i keep making alot of mistaken
> and it fails every time.
> Anyone's interested in helping me ?
> Thanks
> --
> https://mail.python.org/mailman/listinfo/python-list
>

copy the code here.  You will get help, but people don't generally write
programs for others here

-- 
Joel Goldstick
http://joelgoldstick.com/ 
http://cc-baseballstats.info/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[BartC]

On 27/03/2016 14:47, Dennis Lee Bieber wrote:

On Sun, 27 Mar 2016 12:31:26 +0100, BartC  declaimed the
following:


On 27/03/2016 07:34, Paul Rubin wrote:

BartC  writes:

   But my suggestion was to have required a keyword in front of
such expressions.


Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?


They both look like function calls. Function calls are *very* commonly
used as standalone expressions.

You /could/ stipulate that they be written:

   call launch(missiles)# like Fortran iirc


Except that FORTRAN also explicitly defines them as

subroutine xxx()
vs
return-type function yyy()

and will generate a compile error if you "call" the latter, or put the
former in-line of an expression

This would be the equivalent of removing "def" from Python, and adding
two new keywords: "sub" and "fun"; modifying the behavior so that "fun"s
must have an explicit return statement (preferably with an explicit return
value), whereas "sub"s have no return and just ... end...


Well, that could be done in Python (not so usefully because you can't 
take account of such info until a call is attempted), but that's not 
what I'm talking about, which is simply allowing:


  fn(...)

whether fn has an explicit return or not, and not allowing:

  fn # and other kinds of expression

unless some keyword is used. (I've no idea what that might be; all the 
best ones are taken. But I've already said a keyword can be emulated via 
a dummy function call.)


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

Help with python script for NMR

[mohamadmaaz5]

Hello there,
I found a python script in a scientific article that enables a simple 
calculation on an NMR spectrum.
I have no experience in programming and i would appreciate it if i can 
communicate with someone who can write this script and send it to me by mail in 
py format. It's a short script but i keep making alot of mistaken and it fails 
every time.
Anyone's interested in helping me ?
Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why lambda in loop requires default?

[Jussi Piitulainen]

gvim writes:

> Given that Python, like Ruby, is an object-oriented language why
> doesn't this:
>
> def m():
>   a = []
>   for i in range(3): a.append(lambda: i)
>   return a
>
> b = m()
> for n in range(3): print(b[n]())  # =>  2  2  2

I'm going to suggest two variations that may or may not work for you,
with very brief glosses. Just ignore them if you don't see their
relevance.

First, consider:

def w():
  a = []
  for i in range(3): a.append(lambda: i)
  i = "!"
  return a

b = w()
for f in b: print(f()) # => ! ! !

(Those functions depend on the i in the loop.)

> lambda i=i: i
>
> ... is needed to make it work in Python. Just wondered why?

And second, consider: lambda x=i: x

(Those functions are independent of the i in the loop.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: help with program

[Bob Gailer]

The problem with putting input at the end of a program is: if the program
raises an exception you won't see it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Calling the source command from subprocess.popen to update the os.environ.

[Oscar Benjamin]

On 27 Mar 2016 17:01, "Ben Finney"  wrote:
>
> Hongyi Zhao  writes:
>
> > I use the following code the update the os.environ:
> >
> > import os
> > from subprocess import check_output
> >
> > # POSIX: name shall not contain '=', value doesn't contain '\0'
> > output = check_output("source /home/werner/env-intel-toolchains.sh;
> >  env -0", shell=True, executable="/bin/bash")
>
> That will start a new process (running ‘/bin/bash’), then execute some
> commands from a script file in that process.
>
> When that new process ends, any changes in its environment also
> disappear.

...unless the subprocess prints them out or something.

I think you skimmed the code and question a little too quickly.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Announcing the release of Yosai: a security framework for python applications

[Ben Finney]

Darin Gordon  writes:

> I am very glad to announce the first release of Yosai, a security
> framework for python applications.
>
> Details, including link to project:
> http://www.daringordon.com/introducing_yosai

Rather than just a link, can you please give a couple of paragraphs
explaining what is the purpose of the library, and why we might be
interested?

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)to learn.” —Richard M. Stallman, 2002 |
Ben Finney

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

Re: Calling the source command from subprocess.popen to update the os.environ.

[Ben Finney]

Hongyi Zhao  writes:

> I use the following code the update the os.environ:
>
> import os
> from subprocess import check_output
>
> # POSIX: name shall not contain '=', value doesn't contain '\0'
> output = check_output("source /home/werner/env-intel-toolchains.sh;
>  env -0", shell=True, executable="/bin/bash")

That will start a new process (running ‘/bin/bash’), then execute some
commands from a script file in that process.

When that new process ends, any changes in its environment also
disappear.

At no point do changes to that new process's environment have any effect
on the Python process.

A Unix process is *completely unable* to change the environment
variables of its parent. It can change its own variables, and optionally
those of its child processes.

This is by design. It's a good thing.

So if you want the Python process's environment to change, then it needs
to be:

* Inherited from an *already* changed environment when it starts.

Or:

* Changed within the Python process, by the Python API for that purpose
  (‘os.environ’).

You will not be able to change a Python process environment by starting
new processes.

-- 
 \   “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney

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

Why lambda in loop requires default?

[gvim]

Given that Python, like Ruby, is an object-oriented language why doesn't 
this:


def m():
  a = []
  for i in range(3): a.append(lambda: i)
  return a

b = m()
for n in range(3): print(b[n]())  # =>  2  2  2

... work the same as this in Ruby:

def m
  a = []
  (0..2).each {|i| a << ->(){i}}
  a
end

aa = m
(0..2).each {|n| puts aa[n].()}  # =>  0  1  2


lambda i=i: i

... is needed to make it work in Python. Just wondered why?

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

Announcing the release of Yosai: a security framework for python applications

[Darin Gordon]

Hey Everyone!

I am very glad to announce the first release of Yosai, a security framework
for python applications.

Details, including link to project:
http://www.daringordon.com/introducing_yosai


Regards

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

Calling the source command from subprocess.popen to update the os.environ.

[Hongyi Zhao]

Hi all,

Based on the methods here:

http://stackoverflow.com/questions/7040592/calling-the-source-command-
from-subprocess-popen/18897007#comment30954741_12708396

I use the following code the update the os.environ:

import os
from subprocess import check_output

# POSIX: name shall not contain '=', value doesn't contain '\0'
output = check_output("source /home/werner/env-intel-toolchains.sh;
 env -0", shell=True, executable="/bin/bash")

# replace env
os.environ.clear()
os.environ.update(line.partition('=')[::2] for line in output.split('\0'))

In the above code, the file /home/werner/env-intel-toolchains.sh will be 
sourced and its settings should be combined into the current os.environ 
of python.

But, I find that the above code will fail on the `os.environ.clear()' 
command as follows:

In[24]: import os
from subprocess import check_output
# POSIX: name shall not contain '=', value doesn't contain '\0'
output = check_output("source /home/werner/env-intel-toolchains.sh; env 
-0",   shell=True,
  executable="/bin/bash")
# replace env
os.environ.clear()
os.environ.update(line.partition('=')[::2] for line in output.split('\0'))

Traceback (most recent call last):
  File "/home/werner/anaconda2/lib/python2.7/site-packages/IPython/core/
interactiveshell.py", line 3066, in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
  File "", line 10, in 
os.environ.clear()
  File "/home/werner/anaconda2/lib/python2.7/os.py", line 501, in clear
unsetenv(key)
OSError: [Errno 22] Invalid argument

If I don't use the `os.environ.clear()' code line, it will work smoothly.

Any hints?

Regards
-- 
.: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :.
-- 
https://mail.python.org/mailman/listinfo/python-list

EuroPython 2016: More than 150 sessions waiting for you

[M.-A. Lemburg]

Just in case you didn’t find enough Easter eggs today, we have a whole
basket of them waiting for you: the first set of accepted sessions for
EuroPython 2016 in Bilbao.


 *** EuroPython 2016 Session List ***

   https://ep2016.europython.eu/en/events/sessions/


The sessions were selected on the basis of your talk voting and the
work of the EuroPython program work group.  From the around 300
proposals, 156 sessions were chosen for EuroPython 2016 in the first
round:

 * 125 talks
 * 20 training sessions
 * 11 local track talks

We still have several other session types coming (helpdesks, posters,
panels, interactive sessions). These will announced separately.

Early in June we will have a short second Call for Proposals, limited
to hot topics and most recent developments in software and technology.
We will announce details soon.

Many thanks to everyone who submitted proposals. EuroPython wouldn’t
be possible without our speakers.

The program work group will now work on the schedule. Given the
number of sessions, this may take a while, but we’ll try to get it done
as quickly as possible.  The WG is also putting together a submission
waiting list, which will be used to fill slots of speakers who cannot
attend.  Speakers on the waiting list will be contacted by the end of
next week.


  Happy Easter Weekend !


With gravitational regards,
--
EuroPython 2016 Team
http://ep2016.europython.eu/
http://www.europython-society.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[BartC]

On 27/03/2016 07:34, Paul Rubin wrote:

BartC  writes:

  But my suggestion was to have required a keyword in front of
such expressions.


Should there be a keyword in front of a line containing "sqrt(x)" ?
What about "launch(missiles)" ?


They both look like function calls. Function calls are *very* commonly 
used as standalone expressions.


You /could/ stipulate that they be written:

  call launch(missiles)# like Fortran iirc

but that wouldn't be popular and is unnecessary.


The compiler can't tell which of those expressions has a side effect.
The first might be buggy code but the second is idiomatic.


Whether there are side-effects is not quite as important as picking up 
things that are likely to be errors:


  f() # Probably OK
  g() # Probably OK
  f()+g() # Probably not OK

Maybe there is some legitimate, obscure reason for writing the latter, 
but stick some indicator in front to tell the language (and whoever 
happens to be reading the code) that this is what you intend.


In the case of sqrt(), many languages appear to treat maths operators as 
regular functions, so would be hard to justify special treatment. And in 
Python, 'sqrt' could be reassigned to do something different.


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

Re: repeat items in a list

[Antonio Caminero Garcia]

On Sunday, March 27, 2016 at 11:52:22 AM UTC+2, larudwer wrote:
> how about
> 
>   sorted(["a", "b"]*3)
> ['a', 'a', 'a', 'b', 'b', 'b']

that's cooler, less efficient though and do not maintain the original order. In 
case such order was important, you should proceed as follows:

If the elements are unique, this would work:

sorted(sequence*nrep, key=sequence.index)

Otherwise you'd need a more complex key function (maybe a method of a class 
with a static variable that tracks the number of times that such method is 
called and with a "dynamic index functionality" that acts accordingly (i-th 
nrep-group of value v)) and imo it does not worth it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: repeat items in a list

[Jussi Piitulainen]

Antonio Caminero Garcia writes:
> On Saturday, March 26, 2016 at 11:12:58 PM UTC+1, beli...@aol.com wrote:
>> I can create a list that has repeated elements of another list as
>> follows:
>> 
>> xx = ["a","b"]
>> nrep = 3
>> print xx
>> yy = []
>> for aa in xx:
>> for i in range(nrep):
>> yy.append(aa)
>> print yy
>> 
>> output:
>> ['a', 'b']
>> ['a', 'a', 'a', 'b', 'b', 'b']
>> 
>> Is there a one-liner to create a list with repeated elements?
>
> What about this?
>
> def rep_elements(sequence, nrep):
> #return [ritem for item in sequence for ritem in [item]*nrep]
> return list(chain.from_iterable(([item]*nrep for item in sequence)))
>
> sequence = ['h','o','l','a']
> print(rep_elements(sequence,  3))

A thing to know about the comprehension-syntaxes is that they correspond
precisely to nested loops (and conditions, but conditions don't appear
in the present example) with an .append inside.

xx = "ab"
nrep = 3
print([ aa for aa in xx for i in range(nrep) ])

(This has been posted in this thread a few times already, but I think
the systematic correspondence to the original loops was left unstated.
Apologies in advance if I missed something.)

The resulting list has some hidden name. The original loops should be
re-mentalized for an even closer correspondence as follows.

g47 = []
for aa in xx:# Loopy ...
   for i in range(nrep): # ... do!
  g47.append(aa) # <-- _This_ aa is one of the result items.
yy = g47

A thing about range objects is that they can be reused, so the present
example could also reuse just one.

xx = "ab"
reps = range(3)
print([ aa for aa in xx for i in reps ])
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Threading is foobared?

[Tim Golden]

On 27/03/2016 07:25, Random832 wrote:

On Sat, Mar 26, 2016, at 23:18, Ben Finney wrote:

What you've demonstrated is that at least one host is violating
communication standards by altering existing reference fields on
messages in transit.


The usenet gateway relays posts that originated on the mailing list to
usenet with their *Message-ID* replaced wholesale with
"" - 90% of the time when I've traced
a broken thread this has been to blame, and I've complained at least
twice of this before, once not two weeks ago.


And I apologise because I saw that complaint and had meant to reply. In 
short, it's not the list owners who manage the gateway but rather the 
mailman administrators for the whole of the python.org lists. I do 
remember some discussion / explanation of possible problems when the 
mailman version was upgraded a few months ago. I'll try to dig those out 
and follow up with the people involved.


FWIW I assume the issue is with the mail -> news gateway as I see no 
problems with the mailing list threading (at least using TB on Windows) 
and the archive doesn't appear to lose threading either AFAICT. Please 
feel free to point out if I'm wrong about that.


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

Re: repeat items in a list

[larudwer]

how about

 sorted(["a", "b"]*3)
['a', 'a', 'a', 'b', 'b', 'b']


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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Oscar Benjamin]

On 27 Mar 2016 10:56, "Steven D'Aprano"  wrote:
>
>
> My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
> function:
>
> void foo(int n) {
> int i = n + 1;
> bar(i);
> }
>
> There's a possible overflow of a signed int in there. This is undefined
> behaviour. Now, you might think to yourself:
>
> "Well, that's okay. So long as n is not equal to MAXINT, the overflow will
> never occur, which means the undefined behaviour will never occur, which
> means that bar will be called with (n+1) as argument. So foo is safe, so
> long as n is smaller than MAXINT in practice."
>
> And then go on to write something like:
>
> # my C is getting rustier by the second, sorry
> int n = read_from_instrument();
> foo(n);
>
>
> secure in the knowledge that your external hardware instrument generates
> values 0 to 1000 and will never go near MAXINT. But the C compiler doesn't
> know that, so it has to assume that n can be any int, including MAXINT.
> Consequently your foo is "meaningless" and your code can legally be
> replaced by:
>
> int n = read_from_instrument();
> erase_hard_drive();

This is incorrect. Provided n does not take the value INT_MAX the code is
conforming and the standard mandates how it should behave. The compiler is
allowed to make optimisations that assume n never takes that value such
that in the circumstances where n *would* take that value any behaviour is
acceptable. The compiler is not free to say "I don't know if it would take
that value so I'm unconstrained even if it does not".

>
> regardless of the actual value of n. Taken in isolation, of course this is
> absurd, and no compiler would actually do that. But in the context of an
> entire application, it is very difficult to predict what optimizations the
> compiler will take, what code will be eliminated, what code will be
> reordered, and the nett result is that hard drives may be erased, life
> support systems could be turned off, safety systems can be disabled,
> passwords may be exposed, arbitrary code may be run.
>
> I'm sure that there are ways of guarding against this. There are compiler
> directives that you can use to tell the compiler not to optimize the call
> to foo, or command line switches to give warnings, or you might be able to
> guard against this:
>
> int n = read_from_instrument();
> if n < MAXINT {
> foo(n);
> }

This is correct. It is now impossible for the addition n+1 to overflow
since we cannot hit that code if n is INT_MAX.

> But even the Linux kernel devs have been bitten by this sort of thing.
With
> all the warnings and linters and code checkers and multiple reviews by
> experts, people get bitten by undefined behaviour.

I think you're overegging this a bit. Many experienced programmers get
bitten by bugs while working in many languages. C is more troublesome than
many and there is room for improvement but it's not as dramatic as you
suggest.

> What you can't do is say "foo is safe unless n actually equals MAXINT".
> That's wrong. foo is unsafe if the C compiler is unable to determine at
> compile-time whether or not n could ever, under any circumstances, be
> MAXINT. If n might conceivably ever be MAXINT, then the behaviour of foo
is
> undefined. Not implementation-specific, or undocumented. Undefined, in the
> special C meaning of the term.

I think you've misunderstood this: signed addition that would not overflow
is well defined so the optimiser cannot alter the semantics in that case.
It is free to assume that values that would overflow will not occur and
alter execution in surprising ways but that's not the same as rewriting
valid code on the assumption that an invalid value cannot be proven not to
occur. Rather the onus is on the optimiser to prove that the optimised code
is equivalent for all inputs where behaviour is defined.

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

Re: repeat items in a list

[Antonio Caminero Garcia]

On Sunday, March 27, 2016 at 10:02:44 AM UTC+2, Antonio Caminero Garcia wrote:
> On Saturday, March 26, 2016 at 11:12:58 PM UTC+1, beli...@aol.com wrote:
> > I can create a list that has repeated elements of another list as follows:
> > 
> > xx = ["a","b"]
> > nrep = 3
> > print xx
> > yy = []
> > for aa in xx:
> > for i in range(nrep):
> > yy.append(aa)
> > print yy
> > 
> > output:
> > ['a', 'b']
> > ['a', 'a', 'a', 'b', 'b', 'b']
> > 
> > Is there a one-liner to create a list with repeated elements?
> 
> What about this?
> 
> def rep_elements(sequence, nrep):
> #return [ritem for item in sequence for ritem in [item]*nrep]
> return list(chain.from_iterable(([item]*nrep for item in sequence)))
> 
> sequence = ['h','o','l','a']
> print(rep_elements(sequence,  3))

I prefer the commented solution :).

[ritem for item in sequence for ritem in [item]*nrep] # O(len(sequence)*2nrep) 

and the chain solution  would be # O(len(sequence)*nrep). The constants ate 
gone so I prefer the first one for its readibility.

On a practical level:

https://bpaste.net/show/fe3431a13732
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: repeat items in a list

[Antonio Caminero Garcia]

On Saturday, March 26, 2016 at 11:12:58 PM UTC+1, beli...@aol.com wrote:
> I can create a list that has repeated elements of another list as follows:
> 
> xx = ["a","b"]
> nrep = 3
> print xx
> yy = []
> for aa in xx:
> for i in range(nrep):
> yy.append(aa)
> print yy
> 
> output:
> ['a', 'b']
> ['a', 'a', 'a', 'b', 'b', 'b']
> 
> Is there a one-liner to create a list with repeated elements?

What about this?

def rep_elements(sequence, nrep):
#return [ritem for item in sequence for ritem in [item]*nrep]
return list(chain.from_iterable(([item]*nrep for item in sequence)))

sequence = ['h','o','l','a']
print(rep_elements(sequence,  3))
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Rustom Mody]

On Sunday, March 27, 2016 at 1:10:51 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> 
> > No it's not meaningless if it "might" overflow, it's meaningless if it
> > -does- overflow, 
> 
> No! That's exactly wrong!
> 
> Paul, thank you for inadvertently proving the point I am trying to get
> across. People, even experienced C coders, simply don't understand what the
> C standard says and what C compilers can and will do.

Yeah this misunderstanding is a deep one
People find it hard to get the halting problem:

for(;;)
  ;
is an infinite loop.
Whats the big deal?
Why is it 'impossible' to detect?

Its hard because we have to reason all possible inputs (and for language
implementations, all possible programs) when these are yet unavailable
unwritten

JFTR I am not remotely arguing that C is not dangerous.
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html
It was bad in 1991 and has probably got worse with a totally networked world
of nameless hoods.

I am just saying no-C is no-option
[Considering the day it is you may wish to consider prayer :-) ]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Steven D'Aprano]

On Sun, 27 Mar 2016 01:30 am, Chris Angelico wrote:

> On Sun, Mar 27, 2016 at 1:09 AM, BartC  wrote:
>> I'm surprised that both C and Python allow statements that apparently do
>> nothing. In both, an example is:
>>
>>   x
>>
>> on a line by itself. This expression is evaluated, but then any result
>> discarded. If there was a genuine use for this (for example, reporting
>> any error with the evaluation), then it would be simple enough to require
>> a keyword in front.
> 
> Tell me, which of these is a statement that "does nothing"?
> 
> foo
> foo.bar
> foo["bar"]
> foo.__call__
> foo()
> int(foo)
> 
> All of them are expressions to be evaluated and the result discarded.

Right. And with the exception of the first, all of them could call arbitrary
code (a property, __getattr__, __getitem__, etc.) and hence could have
side-effects.

But the first one is special. It can only do two things: evaluate a name,
then silently throw the result away, or raise NameError.

Bart's point is that Python *could* (and arguably should) define the first
one, a bare name, as a SyntaxError. If you want to test for the existence
of a name, you would have to write something like (let's say):

ifundef raw_input:
raw_input = input


One might argue that according to the Zen, this is more Pythonic than the
status quo of a try...except. It's an explicit test of whether a name is
undefined, and it avoids at least some silent errors (where an expression
with no side-effects is evaluated, and the result silently thrown away).

We could argue the pros and cons of the two approaches, or even a more
radical approach like Javascripts where names evaluate as undef if they
haven't been defined yet. But one thing is certain: there is a class of
error which only occurs because it is legal to evaluate a bare name and do
nothing with the result.


> Point is, CPython can generally assume that bug-free code will never
> get anywhere *near* the limit of a signed integer. Consequently, C's
> undefined behaviour isn't a problem; it does NOT mean we need to be
> scared of signed integers.

I think you have badly misunderstood the nature of the problem.

My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
function:

void foo(int n) {
int i = n + 1;
bar(i);
}

There's a possible overflow of a signed int in there. This is undefined
behaviour. Now, you might think to yourself:

"Well, that's okay. So long as n is not equal to MAXINT, the overflow will
never occur, which means the undefined behaviour will never occur, which
means that bar will be called with (n+1) as argument. So foo is safe, so
long as n is smaller than MAXINT in practice."

And then go on to write something like:

# my C is getting rustier by the second, sorry
int n = read_from_instrument();
foo(n);


secure in the knowledge that your external hardware instrument generates
values 0 to 1000 and will never go near MAXINT. But the C compiler doesn't
know that, so it has to assume that n can be any int, including MAXINT.
Consequently your foo is "meaningless" and your code can legally be
replaced by:

int n = read_from_instrument();
erase_hard_drive();


regardless of the actual value of n. Taken in isolation, of course this is
absurd, and no compiler would actually do that. But in the context of an
entire application, it is very difficult to predict what optimizations the
compiler will take, what code will be eliminated, what code will be
reordered, and the nett result is that hard drives may be erased, life
support systems could be turned off, safety systems can be disabled,
passwords may be exposed, arbitrary code may be run.

I'm sure that there are ways of guarding against this. There are compiler
directives that you can use to tell the compiler not to optimize the call
to foo, or command line switches to give warnings, or you might be able to
guard against this:

int n = read_from_instrument();
if n < MAXINT {
foo(n);
}


But even the Linux kernel devs have been bitten by this sort of thing. With
all the warnings and linters and code checkers and multiple reviews by
experts, people get bitten by undefined behaviour.

What you can't do is say "foo is safe unless n actually equals MAXINT".
That's wrong. foo is unsafe if the C compiler is unable to determine at
compile-time whether or not n could ever, under any circumstances, be
MAXINT. If n might conceivably ever be MAXINT, then the behaviour of foo is
undefined. Not implementation-specific, or undocumented. Undefined, in the
special C meaning of the term.



-- 
Steven

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Steven D'Aprano]

On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:

> Steven D'Aprano  writes:
>> For example, would you consider that this isolated C code is
>> "meaningless"?
>> int i = n + 1;
> 
> It's meaningful as long as n is in a certain range of values so there's
> no overflow.
> 
>> But according to the standard, it's "meaningless", since it might
>> overflow, and signed int overflow is Undefined Behaviour.
> 
> No it's not meaningless if it "might" overflow, it's meaningless if it
> -does- overflow, 

No! That's exactly wrong!

Paul, thank you for inadvertently proving the point I am trying to get
across. People, even experienced C coders, simply don't understand what the
C standard says and what C compilers can and will do.

If the C compiler cannot prove that n is strictly less than MAXINT (or is
that spelled INT_MAX?), the *entire program* (or at least the bits
reachable from this line, in both directions) is Undefined, and the
compiler has no obligations at all.

You probably don't believe me because this sounds crazy, something that no
sane person would design a programming language to behave. Well, yeah,
exactly. It does allow C a lot of powerful optimizations, but only at the
cost of making it impossible to reason about the behaviour of code that is
Undefined. No real compiler is going to intentionally erase your hard disk,
but in non-toy code, it can introduce serious bugs even though you
explicitly wrote code to avoid the buggy case.

But don't believe me. What do I know about C, I don't even know whether to
spell the biggest int MAXINT or INT_MAX or MAX_INT. Instead, believe these
guys:

http://blog.regehr.org/archives/213
http://blog.regehr.org/archives/226
http://blog.regehr.org/archives/232

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/

https://randomascii.wordpress.com/2014/05/19/undefined-behavior-can-format-your-drive/


I've emphasised all the bad things that undefined behaviour causes, but the
above (written by C programmers who presumably like C) are much more
even-handed, describing the good things that compilers can get out of this.




-- 
Steven

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

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Steven D'Aprano]

On Sat, 26 Mar 2016 08:23 am, Chris Angelico wrote:

> On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano 
> wrote:

>> Undefined behaviour does not mean "implementation specific behaviour".
>> Nor does it mean "something sensible will happen but we don't promise
>> what it will be". It means "the compiler can do anything", including
>> ignoring the code you actually wrote and substituting its own faster
>> code, which may or may not do what your original code did.
> 
> C's undefined behaviour is basically "you're not allowed to do this".
> The compiler is free to assume that you will never do this, ergo it is
> free to write out machine code that is correct only so long as you do
> not do this. 

Yes, but it's worse than that. The compiler can write out that machine code
*even if you do, in fact, do what it assumes you don't do*. Am I the only
one that thinks that's rather perverse? Probably not, since most
programming languages are safer than C. You don't get this sort of thing
happening even in other low-level languages like Forth. And there is a lot
of work actively trying to build systems languages that are safer than C,
e.g. D and Rust.


> Let me draw a Python analogy: 
> 
> 1) A well-behaved iterator will return values until it raises
> StopIteration, and then raise StopIteration thereafter.
> 2) An iterator which raises and then returns is thus badly written and
> should not exist.

The first part of this is correct: iterators which raise StopIterator, and
then later yield values, are indeed *officially* known as "broken". Here is
a broken iterator:

class Broken:
def __init__(self):
self.x = 0
def __iter__(self):
return self
def __next__(self):
self.x += 1
if self.x < 6:
return self.x
if self.x % 2:
return "NOBODY expects the Spanish Inquisition!"
raise StopIteration


I once asked Guido if "broken" iterators should be considered illegal, or an
error, and if I remember correctly (I'm pretty sure I do, but don't ask me
for a link) he said that they're legal, but you shouldn't write them. If
you want to shoot yourself in the foot with a broken iterator, you can.

So broken iterators (what you call ill-behaved) are not forbidden. They're
just discouraged.

For example, if you create an iterator with a "restart" method, that's
officially broken. But I don't believe anyone would agree that people
should be prohibited from creating a custom iterator that can be restarted.
That sort of heavy-handed prescriptivist approach goes against the 
"consenting adults" philosophy of Python.


> 3) A consumer of an iterator is allowed to misbehave in the event that
> the iterator returns after raising.

Define "misbehave". I think that's the crux of the matter. It's not just
Undefined Behaviour *alone* that is so problematic, but that it is linked
to a culture of aggressive optimization that is prepared to radically
change the semantics of code as compared to what the C abstract machine
would do.

The iterator protocol is defined such that once an iterator raises, it
should continue to raise forever. If you violate that, you're not following
the iterator protocol precisely. That's okay, nobody says you have to. But
if you don't, you can't complain if code behaves strangely.

A similar situation occurs with reflexivity of equality. Python built-ins
are allowed to assume that x == x is always true, and optimize equality
checks as

if a is b: 
# fast path
return True
else:
# slow path

That's great, unless you have NANs or other "weird" objects that violate the
assumption that an object is always equal to itself.

It's not just built-ins: any class or function is allowed to make the same
assumption. In that case, ideally the class or function should document the
fact that it assumes reflexivity, but that's a "quality of implementation"
detail, and we all know that most coders are crap at documentation.


> 4) Therefore an optimizer is free to *cause* the consumer to misbehave
> when given an ill-behaved iterator.

Unlike C, Python has no official IEC standard where the definitive answer to
this (implied) question is written down. We can't look up in the standard
to see what Python implementations can do, but we can try to channel Guido
and the core developers and guess their attitude based on their public
behaviour and the behaviour of the Python reference implementation,
CPython.

I don't believe that Guido or the core developers would take that position.
I expect that they would call that a bug in the optimizer. For example,
here's that broken iterator in action:

py> x = Broken()
py> list(x)
[1, 2, 3, 4, 5]
py> list(x)
['NOBODY expects the Spanish Inquisition!']
py> list(x)
['NOBODY expects the Spanish Inquisition!']
py> list(x)
['NOBODY expects the Spanish Inquisition!']


So the reference implementation shows clearly that broken iterators are
allowed. Until such time as Guido changes his mind, an optimizer that
changed 

Re: Undefined behaviour in C [was Re: The Cost of Dynamism]

[Rustom Mody]

On Sunday, March 27, 2016 at 12:05:01 PM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > eg haskell (ghc) is written in ghc
> > Where did the first bootstrap start from?
> 
> The very earliest Haskell implementation was written in Lisp.

Ummm So you found a little chink in my argument -- Ok :-)
Yeah I remember that Paul Hudak of Yale (now deceased) was working on Haskell
in Yale-scheme (T). I did not know it ever materialized.

However in pragmatic terms I dont think the argument changes; viz.
If you take any technology today (and it may not be remotely connected to
computers eg the chip that controls the car, the credit card's ATM network
layer etc etc, you will invariably find C.
All that you need to do is to work out the transitive-closure of the
implemented-in/interpreted-by relation.
So a C program uses C at 0 removes
A CPython program uses C at at 1
A PyPy program at 2 (or 3 or 4 not likely more than that).

On a funny note:
I was teaching APL and one of the students came and asked me:
Did C exist in 1960?
No Why?
Well You said APL was implemented in 1960 and APL is implemented in C

Nothing to match the power of syllogism :-)

So yes one can in *principle* have a completely C-less world
Just like one can in principle compute the square-root of Graham's number

Likewise a cost of a billion dollars de-C-ification is probably a gross 
underestimate:
See https://en.wikipedia.org/wiki/Rock's_law
-- 
https://mail.python.org/mailman/listinfo/python-list