Return str to a callback raise a segfault if used in string formating

[Vincent Vande Vyvre]

Simplified code:

---%<--
class Foo:
    tasks = []
    def process(self, *args):
    # process with the file
    # save result on disk with a new name
    self.out_filename.write(.)

    def run_multitasks(self):
    while self.tasks:
    t = Thread(target=process, args=self.tasks.pop(0))
    t.start()
    t.join()
    self.callback(self.out_filename)

    def add_task(self, fname, callback):
    self.tasks.append(fname)
    self.callback = callback
    if len(self.tasks) == 1:
    self.run_multitasks()

def slot(filename):
    print(filename) # Works
    print("%s created" % filename)  # Segfault !

Files = [list of files]
foo = Foo()
for f in Files:
    foo.add_task(f, slot)
---%<--

If I place self.callback() at the end of the func process that doesn't 
change anything.



Regards,

Vincent.

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

Re: OT Lies in education [was Re: The "loop and a half"]

[Christian Gollwitzer]

Am 12.10.17 um 01:33 schrieb Chris Angelico:

Yeah. The trouble is that this is a really REALLY bad way to design
something. Have you seen a city that grew one house at a time, and had
streets added to service those houses? Not good. 


I tend to disagree. Many European villages have been built that way, and 
they are lovely for tourists:

https://en.wikipedia.org/wiki/Angerdorf
:)

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

Re: Return str to a callback raise a segfault if used in string formating

[Chris Angelico]

On Fri, Oct 13, 2017 at 4:46 PM, Vincent Vande Vyvre
 wrote:
> Simplified code:
>
> ---%<--
> class Foo:
> tasks = []
> def process(self, *args):
> # process with the file
> # save result on disk with a new name
> self.out_filename.write(.)
>
> def run_multitasks(self):
> while self.tasks:
> t = Thread(target=process, args=self.tasks.pop(0))
> t.start()
> t.join()
> self.callback(self.out_filename)
>
> def add_task(self, fname, callback):
> self.tasks.append(fname)
> self.callback = callback
> if len(self.tasks) == 1:
> self.run_multitasks()
>
> def slot(filename):
> print(filename) # Works
> print("%s created" % filename)  # Segfault !
>
> Files = [list of files]
> foo = Foo()
> for f in Files:
> foo.add_task(f, slot)
> ---%<--
>
> If I place self.callback() at the end of the func process that doesn't
> change anything.

First off, exactly what version of Python are you running this under?
With a segfault, you need to be pretty specific - platform, version,
word size, as much as you can gather.

Secondly: Can you create a version of this that doesn't comment out
part of the work? If you can make a script where, any time you run it,
Python segfaults, that would be extremely helpful.

Your code currently looks a bit weird. You create a thread, start it,
and then immediately wait for it (join()). When you add a task, if
it's the first task you've added, you process tasks, thus removing
that task. So the class isn't actually doing anything, and logically,
you could simply process the files directly in the loop. I'm guessing
that something in there (probably the threading) is causing the crash,
but without a complete and testable demo, it's hard to be sure.

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

Re: unorderable types: list() > int()

[Peter Otten]

Andrew Z wrote:

> Hello,
> pos = {"CLown":10,"BArbie":20}
> I want to return integer (10) for the keyword that starts with "CL"
> 
> 
> cl_ = [v for k, v in pos.items() if k.startswith('CL')]
> cl_pos = cl_[0]
> if cl_pos > 0:
> 
>blah..
> 
> 
> There are 2 issues with the above:
>  a. ugly - cl_pos = cl_ [0] .  I was thinking something like

There's another issue: what do you want to do if there is more than one 
match or no match at all?

If you are OK with a ValueError in both cases you can rewrite

> cl_ = [v for k, v in pos.items() if k.startswith('CL')][0]

[match] = (v for k, v in pos.items() if k.startswith("CL"))

If the values are orderable you can standardise on the minimum or maximum

match = min(v for k, v in pos.items() if k.startswith("CL"))

or if you always want an arbitrary match you can pick the first one 
explicitly:

match = next(v for k, v in pos.items() if k.startswith("CL"))

This will raise a StopIteration if there are no matches.

>   but that is too much for the eyes - in 2 weeks i'll rewrite this into
> something i can understand without banging against the desk.
> So what can be a better approach here ?
> 
> 
> b. in "cl_pos > 0:, cl_pos apparently is still a list. Though the run in a
> python console has no issues and report cl_pos as int.
> 
> 
> Appreciate.


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

Re: Return str to a callback raise a segfault if used in string formating

[Vincent Vande Vyvre]

Le 13/10/17 à 09:23, Chris Angelico a écrit :

On Fri, Oct 13, 2017 at 4:46 PM, Vincent Vande Vyvre
 wrote:

Simplified code:

---%<--
...
---%<--

If I place self.callback() at the end of the func process that doesn't
change anything.

First off, exactly what version of Python are you running this under?
With a segfault, you need to be pretty specific - platform, version,
word size, as much as you can gather.

Secondly: Can you create a version of this that doesn't comment out
part of the work? If you can make a script where, any time you run it,
Python segfaults, that would be extremely helpful.

Your code currently looks a bit weird. You create a thread, start it,
and then immediately wait for it (join()). When you add a task, if
it's the first task you've added, you process tasks, thus removing
that task. So the class isn't actually doing anything, and logically,
you could simply process the files directly in the loop. I'm guessing
that something in there (probably the threading) is causing the crash,
but without a complete and testable demo, it's hard to be sure.

ChrisA


I'm using 3.6.1 in venv

It's not easy to write a runnable code because in this example the 
method process() is too simplified and the code don't reproduce the 
segfault.


The code is an image processing in two parts: the processing himself in 
CPython and an api in Python.


I have written the two parts.

In the real code this is the equivalent of the method process():
--
    def unraw(self, index=0, dest=""):
    """Run the demosaication process.

    Args:
    index -- the index of the image or "all" if there's more than 
one image

 into the file
    dest -- the absolute file name for the image decoded.  If a 
file with

    the same name already exists, it will be overwritten.

    Raise IndexError if index >= self.image_count
    """
    if not self.is_raw:
    fname = os.path.basename(self.filename)
    raise TypeError("RAW file %s not supported!" % fname)

    if index >= self.data["image_count"]:
    raise IndexError("Index of image %s out of range(%s)"
 %(index, self.data["image_count"]))

    multi = 0
    if index == "all":
    multi = 1
    index = 0

    if not dest:
    dest = self.filename

    target = os.path.splitext(dest)[0]
    res = self.raw.demosaicate(index, multi, target)    # This call 
the CPython code

    self.out_filename = self.raw.out_file

    def run_multitasks(self):
    def process(*args):
    fname, idx, oname = args
    self.identify()
    self.unraw(idx, oname)

    while self.tasks:
    t = Thread(target=process, args=self.tasks.pop(0))
    t.start()
    t.join()
    if self.callback:
    self.callback(self.out_filename)


I use a list of 20 files and all files are converted, one by one, 
because the CPython part is not thread safe.


But the real interesting thing is the behaviour in the slot() function.

Examples:
 1 ---
def slot(name):
    if os.path.isfile(name):
    print("Created:", name, type(name))
    print("%s created" % name)

result:
add: /home/vincent/Images/RAW_orig/RAW_CANON_1DSM2.CR2
Scaling with darkness 127, saturation 3712, and
multipliers 2.310656 1.00 1.257116 1.00
AHD interpolation...
Converting to sRGB colorspace...
Created: 
/home/vincent/CPython/py361_venv/pyunraw/unraws/RAW_CANON_1DSM2.tiff 


Erreur de segmentation (core dumped)
--

 2 
def slot(name):
    new = name[:]
    if os.path.isfile(name):
    print("Created:", name, type(name))
    print("New:", new)
    print("%s created" % new)

result:
add /home/vincent/Images/RAW_orig/RAW_CANON_1DSM2.CR2
Scaling with darkness 127, saturation 3712, and
multipliers 2.310656 1.00 1.257116 1.00
AHD interpolation...
Converting to sRGB colorspace...
Created: 
/home/vincent/CPython/py361_venv/pyunraw/unraws/RAW_CANON_1DSM2.tiff 


New: /home/vincent/CPython/py361_venv/pyunraw/unraws/RAW_CANON_1DSM2.tiff
Erreur de segmentation (core dumped)
--

The most important, of course is the name of the new file created and I 
can be satisfied with that, I just need the file name, but it's not a 
reason to ignore the problem.


Vincent

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

Re: Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 05:28, Gregory Ewing  wrote:
> Grant Edwards wrote:
>> On 2017-10-13, Stefan Ram  wrote:
>>>  1 byte
>>>
>>>  addressable unit of data storage large enough to hold
>>>  any member of the basic character set of the execution
>>>  environment«
>>>
>>>ISO C standard
>
> Hmmm. So an architecture with memory addressed in octets
> and Unicode as the basic character set would have a
> char of 8 bits and a byte of 32 bits?

No, because a char is also "large enough to store any member of the
basic execution character set. (§6.2.5). A "byte" is just the amount of
storage a "char" occupies:

| The sizeof operator yields the size (in bytes) of its operand
[...]
| When applied to an operand that has type char, unsigned char, or signed
| char, (or a qualified version thereof) the result is 1. 
(§6.5.3.4)

So if a C implementation used Unicode as the base character set, a byte
would have to be at least 21 bits, a char the same, and all other types
would have to be multiples of that. For any modern architecture that
would be rounded up to 32 bits. (I am quite certain that there was at
least one computer with a 21 bit word size, but I can't find it: Lots of
18 bit and 24 bit machines, but nothing in between.)

An implementation could also choose the BMP as the base character set
and the rest of Unicode as the extended character set. That would result
in a 16 bit byte and char (and most likely UTF-16 as the multibyte
character representation).


> Not only does "byte" not always mean "8 bits", but
> "char" isn't always short for "character"...

True. A character often occupies more space than a char, and you can
store non-character data in a char.

hp


-- 
   _  | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| |   | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Return str to a callback raise a segfault if used in string formating

[Thomas Jollans]

On 2017-10-13 11:07, Vincent Vande Vyvre wrote:
> Le 13/10/17 à 09:23, Chris Angelico a écrit :
>> On Fri, Oct 13, 2017 at 4:46 PM, Vincent Vande Vyvre
>>  wrote:
>>> Simplified code:
>>>
>>> ---%<--
>>> ...
>>> ---%<--
>>>
>>> If I place self.callback() at the end of the func process that doesn't
>>> change anything.
>> First off, exactly what version of Python are you running this under?
>> With a segfault, you need to be pretty specific - platform, version,
>> word size, as much as you can gather.
>>
>> Secondly: Can you create a version of this that doesn't comment out
>> part of the work? If you can make a script where, any time you run it,
>> Python segfaults, that would be extremely helpful.
>>
>> Your code currently looks a bit weird. You create a thread, start it,
>> and then immediately wait for it (join()). When you add a task, if
>> it's the first task you've added, you process tasks, thus removing
>> that task. So the class isn't actually doing anything, and logically,
>> you could simply process the files directly in the loop. I'm guessing
>> that something in there (probably the threading) is causing the crash,
>> but without a complete and testable demo, it's hard to be sure.
>>
>> ChrisA
> 
> I'm using 3.6.1 in venv
> 
> It's not easy to write a runnable code because in this example the
> method process() is too simplified and the code don't reproduce the
> segfault.

That is what you'll have to do, though.
If you strip out as much as possible to create a minimal, working,
complete example, you will have a much easier time reasoning about what
is happening. This will also allow other people to reproduce the
problem, and help.

> The code is an image processing in two parts: the processing himself in
> CPython and an api in Python.

If you have custom C code, it's likely that there is a memory management
problem there. It's not unusual for incorrect memory management to cause
problems in a completely different part of the code, where something
tries to access freed memory or something.

If removing a call to C fixes it, I recommend you carefully check the
memory management logic of your C function.


> 
> I have written the two parts.
> 
> In the real code this is the equivalent of the method process():
> --
>     def unraw(self, index=0, dest=""):
>     """Run the demosaication process.
> 
>     Args:
>     index -- the index of the image or "all" if there's more than
> one image
>  into the file
>     dest -- the absolute file name for the image decoded.  If a file
> with
>     the same name already exists, it will be overwritten.
> 
>     Raise IndexError if index >= self.image_count
>     """
>     if not self.is_raw:
>     fname = os.path.basename(self.filename)
>     raise TypeError("RAW file %s not supported!" % fname)
> 
>     if index >= self.data["image_count"]:
>     raise IndexError("Index of image %s out of range(%s)"
>  %(index, self.data["image_count"]))
> 
>     multi = 0
>     if index == "all":
>     multi = 1
>     index = 0
> 
>     if not dest:
>     dest = self.filename
> 
>     target = os.path.splitext(dest)[0]
>     res = self.raw.demosaicate(index, multi, target)    # This call
> the CPython code
>     self.out_filename = self.raw.out_file
> 
>     def run_multitasks(self):
>     def process(*args):
>     fname, idx, oname = args
>     self.identify()
>     self.unraw(idx, oname)
> 
>     while self.tasks:
>     t = Thread(target=process, args=self.tasks.pop(0))
>     t.start()
>     t.join()
>     if self.callback:
>     self.callback(self.out_filename)
> 
> 
> I use a list of 20 files and all files are converted, one by one,
> because the CPython part is not thread safe.
> 
> But the real interesting thing is the behaviour in the slot() function.
> 
> Examples:
>  1 ---
> def slot(name):
>     if os.path.isfile(name):
>     print("Created:", name, type(name))
>     print("%s created" % name)
> 
> result:
> add: /home/vincent/Images/RAW_orig/RAW_CANON_1DSM2.CR2
> Scaling with darkness 127, saturation 3712, and
> multipliers 2.310656 1.00 1.257116 1.00
> AHD interpolation...
> Converting to sRGB colorspace...
> Created:
> /home/vincent/CPython/py361_venv/pyunraw/unraws/RAW_CANON_1DSM2.tiff
> 
> Erreur de segmentation (core dumped)
> --
> 
>  2 
> def slot(name):
>     new = name[:]
>     if os.path.isfile(name):
>     print("Created:", name, type(name))
>     print("New:", new)
>     print("%s created" % new)
> 
> result:
> add /ho

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 07:16, Gregory Ewing wrote:

Steve D'Aprano wrote:

On Fri, 13 Oct 2017 03:37 pm, Gregory Ewing wrote:


If the compiler can tell where p is initially pointing, it could
put the pointer in read-only memory.


If it's read-only, how can the compiler write to it?

(I come from the days when ROM was actual ROM, burned in at the factory.)


So, the factory is allowed to write to it. Possibly
it's writing data that came from... a compiler?

A memory that couldn't be written to at all, ever, would
be a bit useless!



It's read-only in the same sense as a printed book; you can't change the 
marks already on the page.


I've programmed EPROMS. Neither the C language nor the concept of 
'const' attributes for data ever came into it. While executable code 
doesn't really need it.


It is simply not a necessity. You just arranged for writeable portions 
of memory to be at different locations than that containing the code and 
fixed data. Sometimes it was only data.


'const' is anyway the wrong sort of attribute to use, as I've already 
explained. For example:


  const int A = rand();  // inside a function

A is written to multiple times at runtime. It can't go into actual 
read-only memory like a ROM. And it might have trouble going into a 
memory page with read-only attributes.


'const' tries to do too many things, most of them poorly, although it 
does a very good job at adding clutter.


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

Re: Return str to a callback raise a segfault if used in string formating

[Paul Moore]

As a specific suggestion, I assume the name of the created file is a
string object constructed in the C extension code, somehow. The fact
that you're getting the segfault with some uses of that string
(specifically, passing it to %-formatting) suggests that there's a bug
in the C code that constructs that string. That's where I'd start by
looking. Maybe something isn't zero-terminated that should be? Maybe
your code doesn't set up the character encoding information correctly?

Paul

On 13 October 2017 at 11:15, Thomas Jollans  wrote:
> On 2017-10-13 11:07, Vincent Vande Vyvre wrote:
>> Le 13/10/17 à 09:23, Chris Angelico a écrit :
>>> On Fri, Oct 13, 2017 at 4:46 PM, Vincent Vande Vyvre
>>>  wrote:
 Simplified code:

 ---%<--
 ...
 ---%<--

 If I place self.callback() at the end of the func process that doesn't
 change anything.
>>> First off, exactly what version of Python are you running this under?
>>> With a segfault, you need to be pretty specific - platform, version,
>>> word size, as much as you can gather.
>>>
>>> Secondly: Can you create a version of this that doesn't comment out
>>> part of the work? If you can make a script where, any time you run it,
>>> Python segfaults, that would be extremely helpful.
>>>
>>> Your code currently looks a bit weird. You create a thread, start it,
>>> and then immediately wait for it (join()). When you add a task, if
>>> it's the first task you've added, you process tasks, thus removing
>>> that task. So the class isn't actually doing anything, and logically,
>>> you could simply process the files directly in the loop. I'm guessing
>>> that something in there (probably the threading) is causing the crash,
>>> but without a complete and testable demo, it's hard to be sure.
>>>
>>> ChrisA
>>
>> I'm using 3.6.1 in venv
>>
>> It's not easy to write a runnable code because in this example the
>> method process() is too simplified and the code don't reproduce the
>> segfault.
>
> That is what you'll have to do, though.
> If you strip out as much as possible to create a minimal, working,
> complete example, you will have a much easier time reasoning about what
> is happening. This will also allow other people to reproduce the
> problem, and help.
>
>> The code is an image processing in two parts: the processing himself in
>> CPython and an api in Python.
>
> If you have custom C code, it's likely that there is a memory management
> problem there. It's not unusual for incorrect memory management to cause
> problems in a completely different part of the code, where something
> tries to access freed memory or something.
>
> If removing a call to C fixes it, I recommend you carefully check the
> memory management logic of your C function.
>
>
>>
>> I have written the two parts.
>>
>> In the real code this is the equivalent of the method process():
>> --
>> def unraw(self, index=0, dest=""):
>> """Run the demosaication process.
>>
>> Args:
>> index -- the index of the image or "all" if there's more than
>> one image
>>  into the file
>> dest -- the absolute file name for the image decoded.  If a file
>> with
>> the same name already exists, it will be overwritten.
>>
>> Raise IndexError if index >= self.image_count
>> """
>> if not self.is_raw:
>> fname = os.path.basename(self.filename)
>> raise TypeError("RAW file %s not supported!" % fname)
>>
>> if index >= self.data["image_count"]:
>> raise IndexError("Index of image %s out of range(%s)"
>>  %(index, self.data["image_count"]))
>>
>> multi = 0
>> if index == "all":
>> multi = 1
>> index = 0
>>
>> if not dest:
>> dest = self.filename
>>
>> target = os.path.splitext(dest)[0]
>> res = self.raw.demosaicate(index, multi, target)# This call
>> the CPython code
>> self.out_filename = self.raw.out_file
>>
>> def run_multitasks(self):
>> def process(*args):
>> fname, idx, oname = args
>> self.identify()
>> self.unraw(idx, oname)
>>
>> while self.tasks:
>> t = Thread(target=process, args=self.tasks.pop(0))
>> t.start()
>> t.join()
>> if self.callback:
>> self.callback(self.out_filename)
>> 
>>
>> I use a list of 20 files and all files are converted, one by one,
>> because the CPython part is not thread safe.
>>
>> But the real interesting thing is the behaviour in the slot() function.
>>
>> Examples:
>>  1 ---
>> def slot(name):
>> if os.path.isfile(name):
>> print("Created:", name, type(name))
>> prin

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Fri, 13 Oct 2017 05:16 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> On Fri, 13 Oct 2017 03:37 pm, Gregory Ewing wrote:
>> 
>>>If the compiler can tell where p is initially pointing, it could
>>>put the pointer in read-only memory.
>> 
>> If it's read-only, how can the compiler write to it?
>> 
>> (I come from the days when ROM was actual ROM, burned in at the factory.)
> 
> So, the factory is allowed to write to it. Possibly
> it's writing data that came from... a compiler?

The data could come from anywhere, including a scanner:

https://hackaday.com/2012/08/24/uncovering-easter-eggs-in-old-mac-roms/

I wasn't questioning where the data came from, but how the compiler can write
to READ ONLY MEMORY which might not even be in the same continent as the
compiler that generated the code.

Read-only memory (ROM) is typically burned into the silicon by the integrated
chip manufacturer at the factory:

https://en.wikipedia.org/wiki/Mask_ROM

or written by a dedicated hardware device:

https://en.wikipedia.org/wiki/Programmable_read-only_memory

Whether the data is burned into the silicon or electrically written by a
dedicated device, it isn't written by the compiler, and once written the data
is permanent.


> A memory that couldn't be written to at all, ever, would
> be a bit useless!

Macs used a ROM for at least a decade and probably more. The ROM contained
data such as mouse cursors, toolbox routines, icons, sounds, and a
bootloader. No Mac was capable of writing to their ROMs any more than they
could write to their mouse or a CD-ROM.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

bartc :
> 'const' tries to do too many things, most of them poorly, although it
> does a very good job at adding clutter.

+1


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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

"Peter J. Holzer" :

> On 2017-10-13 05:28, Gregory Ewing  wrote:
>> Not only does "byte" not always mean "8 bits", but
>> "char" isn't always short for "character"...
>
> True.

Well, it does, in my universe. That was cast in stone 10**-32 seconds
after the Big Bang.


Marko


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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

Marko Rauhamaa :

> bartc :
>> 'const' tries to do too many things, most of them poorly, although it
>> does a very good job at adding clutter.
>
> +1

However, I do my best to honor "const" since it's there. I'm even more
Catholic than the Pope and declare:

   int main(int argc, const char *const argv[])

I generally *don't* use "const" with opaque data types.


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

Re: Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 10:37, Steve D'Aprano  wrote:
> On Fri, 13 Oct 2017 05:16 pm, Gregory Ewing wrote:
>> Steve D'Aprano wrote:
>>> On Fri, 13 Oct 2017 03:37 pm, Gregory Ewing wrote:
>>> 
If the compiler can tell where p is initially pointing, it could
put the pointer in read-only memory.
>>> 
>>> If it's read-only, how can the compiler write to it?
>>> 
>>> (I come from the days when ROM was actual ROM, burned in at the factory.)
>> 
>> So, the factory is allowed to write to it. Possibly
>> it's writing data that came from... a compiler?
>
> The data could come from anywhere, including a scanner:
>
> https://hackaday.com/2012/08/24/uncovering-easter-eggs-in-old-mac-roms/
>
> I wasn't questioning where the data came from, but how the compiler can write
> to READ ONLY MEMORY which might not even be in the same continent as the
> compiler that generated the code.

A compiler rarely writes into the final destination memory (JIT
compilers are the exception). It writes into a file. This file often has
sections like "code", "read-only data", etc. Another tool (maybe the
OS, maybe an EPROM burner) will later read this file and take
appropriate actions.

"the compiler could put the pointer in read-only memory" is just
shorthand for "the compile could put the pointer into one of the
read-only sections of the object file".


> Read-only memory (ROM) is typically burned into the silicon by the integrated
> chip manufacturer at the factory:
>
> https://en.wikipedia.org/wiki/Mask_ROM

In this case there will be tool (or more likely a whole tool-chain)
which takes the read-only sections of the object file and converts them
into a lithographic mask which will then be used to create chips. The
pointer will end up as a bunch of transistors.


> or written by a dedicated hardware device:
>
> https://en.wikipedia.org/wiki/Programmable_read-only_memory

And in this case there will be a tool which will read the object file
and send the contents of the read-only sections to the device which
writes the ((E)E)PROM.

And finally, the most frequent case: The OS will will read the
executable into RAM, mark those pages from the read-only sections as
read-only in the page table and start it.

> Whether the data is burned into the silicon or electrically written by a
> dedicated device, it isn't written by the compiler, and once written the data
> is permanent.

Did anyone claim that?

>> A memory that couldn't be written to at all, ever, would be a bit
>> useless!
>
> Macs used a ROM for at least a decade and probably more. The ROM contained
> data such as mouse cursors, toolbox routines, icons, sounds, and a
> bootloader. No Mac was capable of writing to their ROMs any more than they
> could write to their mouse or a CD-ROM.

Did anyone claim that?

hp


-- 
   _  | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| |   | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Return str to a callback raise a segfault if used in string formating

[Vincent Vande Vyvre]

Le 13/10/17 à 12:39, Paul Moore a écrit :

As a specific suggestion, I assume the name of the created file is a
string object constructed in the C extension code, somehow. The fact
that you're getting the segfault with some uses of that string
(specifically, passing it to %-formatting) suggests that there's a bug
in the C code that constructs that string. That's where I'd start by
looking. Maybe something isn't zero-terminated that should be? Maybe
your code doesn't set up the character encoding information correctly?

Paul
That was my first idea, because I can verify the instance of PyUnraw is 
not destroyed when I use the file name, but I was in trouble by the 
usage of the file name in string formatting.


For example I can use the file name into the slot i.e. 
shutil.copy(fname, "path/renamed.tiff")

The file is correctly copied.

In fact, I can do anything with the file name except use it in string 
formatting, then your approach is probably a good way.


Into the CPython part I have a c-string pythonized by:
    temp = self->outfname;
    self->outfname = PyUnicode_FromString(ofname);
    Py_XDECREF(temp);

and exposed to Python with:
static PyMemberDef PyUnraw_members[] = {
    {"out_file", T_OBJECT_EX, offsetof(PyUnraw, outfname), 0,
 "Path of the decoded file"},
    ...

Vincent



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

Re: Return str to a callback raise a segfault if used in string formating

[Paul Moore]

On 13 October 2017 at 12:18, Vincent Vande Vyvre
 wrote:
> Le 13/10/17 à 12:39, Paul Moore a écrit :
>>
>> As a specific suggestion, I assume the name of the created file is a
>> string object constructed in the C extension code, somehow. The fact
>> that you're getting the segfault with some uses of that string
>> (specifically, passing it to %-formatting) suggests that there's a bug
>> in the C code that constructs that string. That's where I'd start by
>> looking. Maybe something isn't zero-terminated that should be? Maybe
>> your code doesn't set up the character encoding information correctly?
>>
>> Paul
>
> That was my first idea, because I can verify the instance of PyUnraw is not
> destroyed when I use the file name, but I was in trouble by the usage of the
> file name in string formatting.
>
> For example I can use the file name into the slot i.e. shutil.copy(fname,
> "path/renamed.tiff")
> The file is correctly copied.
>
> In fact, I can do anything with the file name except use it in string
> formatting, then your approach is probably a good way.
>
> Into the CPython part I have a c-string pythonized by:
> temp = self->outfname;
> self->outfname = PyUnicode_FromString(ofname);
> Py_XDECREF(temp);
>
> and exposed to Python with:
> static PyMemberDef PyUnraw_members[] = {
> {"out_file", T_OBJECT_EX, offsetof(PyUnraw, outfname), 0,
>  "Path of the decoded file"},

OK. I presume ofname is UTF-8 encoded as required by
PyUnicode_FromString, and you're not accidentally getting a different
encoding?

I don't see any obvious issue - but it's still far more likely it's an
issue in the C code somewhere. Maybe a refcounting bug - those often
trigger peculiar errors as memory gets freed too soon, and something
then references freed memory.

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

Re: Lies in education [was Re: The "loop and a half"]

[Gregory Ewing]

Steve D'Aprano wrote:

I wasn't questioning where the data came from, but how the compiler can write
to READ ONLY MEMORY which might not even be in the same continent as the
compiler that generated the code.


I thought it would be fairly obvious that by "put it in
read-only memory" I meant "arrange for it to be in a
location that is read-only at run time". Obviously it
can't be read-only at *compile* time, just as a
physical ROM can't be read-only at manufacture time.

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

Re: Lies in education [was Re: The "loop and a half"]

[Gregory Ewing]

Neil Cerutti wrote:

I can tell at a glance if a parameter is expected to be
modifiable just by looking at the function signature.


The question is why doesn't anyone feel the need to be
able to do that for Python functions? Whether a function
modifies things passed to it is just as important to
know in Python as it is in C.

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

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 12:49, Peter J. Holzer wrote:

On 2017-10-13 10:37, Steve D'Aprano  wrote:



or written by a dedicated hardware device:

https://en.wikipedia.org/wiki/Programmable_read-only_memory


And in this case there will be a tool which will read the object file
and send the contents of the read-only sections to the device which
writes the ((E)E)PROM.


First time I did this was with a home-made programmer directly connected 
to a keyboard. I had to press the right key to generate the 7-bit 
pattern I wanted (I can't remember what I did about the 8th bit), burn 
it into the current location then step the address counter to the next.


No mistakes were tolerated. It worked.


And finally, the most frequent case: The OS will will read the
executable into RAM, mark those pages from the read-only sections as
read-only in the page table and start it.


Or as I did it, on a home-made computer with two banks of 16KB RAM, one 
bank had the editor, compiler and source code, the other the generated 
code. Just before running it, I would flip a switch to write-protect the 
first bank in case something went wrong. (I didn't have floppies only 
slow, unreliable tape, so things had to be memory-resident as much as 
possible.)


And, actually, even now machines don't have that much control: you 
create a large table of data at runtime, but it is still in writeable 
memory, and accidental or malicious code could write into it.


No matter that the C source may have had a few consts sprinkled about. 
(It's bit like those incredibly annoying anti-piracy messages and videos 
you get on DVDS. No actual pirate would ever see them, only honest 
people who have no intention of copying!)


Even if data is actually in write-protected memory, attempts to write to 
it will cause a crash. On my home-made system, they just did nothing. 
Much more graceful.


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

Re: Lies in education [was Re: The "loop and a half"]

[Chris Angelico]

On Sat, Oct 14, 2017 at 12:00 AM, bartc  wrote:
> Even if data is actually in write-protected memory, attempts to write to it
> will cause a crash. On my home-made system, they just did nothing. Much more
> graceful.

The novice thinks his job is to stop the program from crashing. The
expert knows that a crash is actually far FAR better than silently
doing nothing.

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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

Gregory Ewing :

> Neil Cerutti wrote:
>> I can tell at a glance if a parameter is expected to be modifiable
>> just by looking at the function signature.
>
> The question is why doesn't anyone feel the need to be able to do that
> for Python functions? Whether a function modifies things passed to it
> is just as important to know in Python as it is in C.

I often ponder what information should be conveyed by the declaration.
For example, some methods are called with lock taken while others not.
Should that be indicated in the name of the function? Also ownership and
other contractual matters.

I occasionally fall into the temptation of coding such aspects in names,
but equally often the attempt backfires. Most you get is silly syntactic
clutter.

Let's just say that the problem remains unsolved, maybe unsolvable, and
any attempts at solving the problem seem to cause worse problems.

BTW, the original reason for C requiring declarations in the first place
wasn't readability. Rather, it was to make compilation possible in the
first place. It is interesting that C++ and Java have taken steps to
remove such information where the compiler can know or guess it from the
context.


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

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 14:16, Chris Angelico wrote:

On Sat, Oct 14, 2017 at 12:00 AM, bartc  wrote:

Even if data is actually in write-protected memory, attempts to write to it
will cause a crash. On my home-made system, they just did nothing. Much more
graceful.


The novice thinks his job is to stop the program from crashing. The
expert knows that a crash is actually far FAR better than silently
doing nothing.



For a novice, seeing 'Segmentation fault (core dumped)' is better?

There, a friendlier, more useful error message is called for ('writing 
into read-only memory' is a good start).


But the idea of having memory which is permanently or temporarily 
write-protected is also useful: you can do what you like to it and it 
won't change, and such an attempt wouldn't necessarily be an error.


For example, you're drawing a series of points or connected lines into a 
window to form a shape. But part of the shape is outside the window. So 
you fix the logic and try again. You don't want it to crash if you gave 
it coordinates (corresponding to memory beyond the window limits) 
outside the boundaries.


It's just a technique, like greying out certain menu options - clicking 
them will do nothing, but you won't get an error message and you don't 
want to allow them anyway, risking more serious consequences.


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

Re: Lies in education [was Re: The "loop and a half"]

[Paul Moore]

On 13 October 2017 at 13:54, Gregory Ewing  wrote:
> Neil Cerutti wrote:
>>
>> I can tell at a glance if a parameter is expected to be
>> modifiable just by looking at the function signature.
>
>
> The question is why doesn't anyone feel the need to be
> able to do that for Python functions? Whether a function
> modifies things passed to it is just as important to
> know in Python as it is in C.

While I don't *really* know, my intuition is that const is important
in C for guaranteeing that functions don't mess around with the
innards of (conceptually) primitive types. Hence const char *, and
const pointers/arrays. More complex types like collections - lists,
trees, etc - can't be declared as "const". Well, they can, but
typically that doesn't guarantee that the collection isn't changed,
just that the pointer to it isn't.

So in C, for all practical purposes const signifies that an argument
is what in languages like C# would be called a value type - an
immutable primitive value.

In Python and other higher level languages, primitive types are
immutable by default, or to put it another way, basic types are always
value types, and constness is part of the definition of the *type*
rather than of the name referring to it. So there's no need for an
explicit "const" annotation.

To put it another way, in C const is a property of the variable being
declared, not the value assigned to it. In Python, variables aren't
declared, and constness is an inherent property of the value (or its
type). One interesting question which this does raise is whether
there's a place for "const" in type annotations - I suspect not,
because it's either trivial (the type is immutable) or too hard to
define (you'd need to recursively know for all methods whether they
mutate the value).

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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

Paul Moore :

> To put it another way, in C const is a property of the variable being
> declared, not the value assigned to it. In Python, variables aren't
> declared, and constness is an inherent property of the value (or its
> type). One interesting question which this does raise is whether
> there's a place for "const" in type annotations - I suspect not,
> because it's either trivial (the type is immutable) or too hard to
> define (you'd need to recursively know for all methods whether they
> mutate the value).

I don't think that's the core issue.

User-defined classes (or, rather, objects) are often mutable. The
question is who gets to modify them and what modifieds them (methods can
have surprising side effects).

"Const" would convey some of that information. However, why "const" out
of the myriads of restrictions?

The nice thing about Python is that I don't get to formally declare
those things, and that makes my life easier. I don't have to worry about
finding the right combination of these formal comments -- because I
can't!


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

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 14:22, Marko Rauhamaa wrote:


BTW, the original reason for C requiring declarations in the first place
wasn't readability. Rather, it was to make compilation possible in the
first place. It is interesting that C++ and Java have taken steps to
remove such information where the compiler can know or guess it from the
context.



The compiler might be able to, after analysing 100,000 lines of prior 
code and applying complex algorithms.


But what about the poor user reading the code? Or can that now only be 
done with the aid or a browser that analyses 100,000 lines and applies 
that same algorithm?


We mustn't forget the person writing the code, who may have a certain 
type in mind for X, but their (I nearly said 'his') analysis may not 
match the compiler's.


Annotations can be useful.

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

Re: Lies in education [was Re: The "loop and a half"]

[Chris Angelico]

On Sat, Oct 14, 2017 at 12:51 AM, bartc  wrote:
> On 13/10/2017 14:16, Chris Angelico wrote:
>>
>> On Sat, Oct 14, 2017 at 12:00 AM, bartc  wrote:
>>>
>>> Even if data is actually in write-protected memory, attempts to write to
>>> it
>>> will cause a crash. On my home-made system, they just did nothing. Much
>>> more
>>> graceful.
>>
>>
>> The novice thinks his job is to stop the program from crashing. The
>> expert knows that a crash is actually far FAR better than silently
>> doing nothing.
>
>
>
> For a novice, seeing 'Segmentation fault (core dumped)' is better?

Better than silently doing nothing? YES. Absolutely it is.

> There, a friendlier, more useful error message is called for ('writing into
> read-only memory' is a good start).

Minor distinction. Yes, it might be helpful to have different error
messages for different errors, but it's a trade-off.

> But the idea of having memory which is permanently or temporarily
> write-protected is also useful: you can do what you like to it and it won't
> change, and such an attempt wouldn't necessarily be an error.
>
> For example, you're drawing a series of points or connected lines into a
> window to form a shape. But part of the shape is outside the window. So you
> fix the logic and try again. You don't want it to crash if you gave it
> coordinates (corresponding to memory beyond the window limits) outside the
> boundaries.

It's common to emulate an infinite drawable area and then optimizing
it by displaying only the part that's outside the window. That's not
the same thing as silently doing nothing if something goes wrong - for
instance, ignoring one point in the shape, and drawing a shape with
fewer points. That would, in my opinion, be utterly unacceptable. And
yes, I've seen programs that do that - it's usually called a "glitch".

> It's just a technique, like greying out certain menu options - clicking them
> will do nothing, but you won't get an error message and you don't want to
> allow them anyway, risking more serious consequences.

Even there, you often CAN get a report about the failure; clicking on
something that's disabled will cause a short beep, unless that's
disabled. Maybe you personally don't like that beep, and you'd rather
it be suppressed - but that's the end user's choice, NOT the
programmer's. "Errors should never pass silently, unless explicitly
silenced."

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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

bartc :

> But what about the poor user reading the code? Or can that now only be
> done with the aid or a browser that analyses 100,000 lines and applies
> that same algorithm?
>
> We mustn't forget the person writing the code, who may have a certain
> type in mind for X, but their (I nearly said 'his') analysis may not
> match the compiler's.
>
> Annotations can be useful.

The writer of the code is responsible for clear communication. However,
I don't believe boilerplate is the answer, quite the contrary.


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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Fri, 13 Oct 2017 11:48 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> I wasn't questioning where the data came from, but how the compiler can
>> write to READ ONLY MEMORY which might not even be in the same continent as
>> the compiler that generated the code.
> 
> I thought it would be fairly obvious that by "put it in
> read-only memory" I meant "arrange for it to be in a
> location that is read-only at run time". Obviously it
> can't be read-only at *compile* time, just as a
> physical ROM can't be read-only at manufacture time.

No, its not obvious.

It is a lot less obvious than my reference to ROM being burnt into hardware at
a factory, which you responded to with the irrelevant observation that the
data originated from a compiler.

Sure, some data in ROMs might come from a compiler -- and some of it might
not. Suppose a ROM contains a list of the names of the computer's developers
(as some Mac ROMs did). It would be an abuse of language to say 

"The text editor writes to the ROM"

and it is equally an abuse to say that the compiler writes to ROM just because
the data burned into the chip is some sort of compiled object code. As Peter
Holzer points out, the compiler likely writes to an object file, not the ROM,
and as I pointed out, the process manufacturing the ROM might not even be in
the same continent as the compiler.

So when you talk about Read Only Memory, you're apparently not actually
talking about actual Read Only Memory (ROM).

Something has to write this data to "read only memory", and it must be able to
do it over and over and over again, each time the program runs. How is this
*read only*? It's not even "Write Once, Read Many" (WORM). What sort of read
only memory can be written to over and over again?

(This is not a rhetorical question.)

It seems to me that you're not talking about ROM at all, but ordinary RAM.
Then what do you mean by "read only"? A block of memory with a flag that
says "unprivileged processes are prohibited from writing here"?

(That's also not a rhetorical question.)

Since the compiler is an unprivileged process, how can it write to memory that
unprivileged processes cannot write to? I'm guessing that it can't. Can it?
If not, then its probably some privileged process (part of the OS?) which
does the writing. Am I close?

(Still not a rhetorical question.)

Earlier you said:

If the compiler can tell where p is initially pointing, it could
put the pointer in read-only memory.

i.e. that you believe it is the *compiler* doing the writing. If that's not
actually what you meant, then what you meant is not sufficiently clear.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Fri, 13 Oct 2017 11:54 pm, Gregory Ewing wrote:

> Neil Cerutti wrote:
>> I can tell at a glance if a parameter is expected to be
>> modifiable just by looking at the function signature.
> 
> The question is why doesn't anyone feel the need to be
> able to do that for Python functions? Whether a function
> modifies things passed to it is just as important to
> know in Python as it is in C.

Lots of people would like Python to have a "freeze" function that can make
immutable objects, it is a moderately common feature request.

Some people (myself included) would like a "const" declaration that gives us
names that can only be bound to once:

const spam = "NOBODY expects the Spanish Inquisition!!!"  # Okay
spam = "foo"  # Error.


I don't mind if that is a runtime error, although a compile time error would
be nicer.

I don't know if either of these (actual immutable pure-Python objects, and
un-rebindable names) count as quite the same thing you are asking Neil about.
But I trust they're related.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Chris Angelico]

On Sat, Oct 14, 2017 at 1:32 AM, Steve D'Aprano
 wrote:
> It seems to me that you're not talking about ROM at all, but ordinary RAM.
> Then what do you mean by "read only"? A block of memory with a flag that
> says "unprivileged processes are prohibited from writing here"?
>
> (That's also not a rhetorical question.)

When I first learned about Protected Mode (as defined by the Intel
80386 and used in OS/2), there was a real concept of read-only RAM.
The program loader would fetch up the executable file (data on the
disk) and construct its segments: code, data, and BSS/stack. The data,
BSS, and stack all end up as a single segment (data is what comes
straight off the disk, BSS is all zeroes initially, and stack is
uninitialized initially, but ultimately they're all read/write), and
code is in its own segment. When control is handed to the new process,
its segment table grants it read/write access to the data/stack
segment, but read-only access to its code segment. Within that
process, the code really truly is read-only, unless some magic is
done. And yes, since it is fully readable, constant data CAN be
included alongside actual executable code, but it's never going to be
mutable in any way.

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

Re: Lies in education [was Re: The "loop and a half"]

[Julien Salort]

Le 12/10/2017 à 17:57, bartc a écrit :

With a const struct, you are stopped from directly modifying elements, 
but if an element is a pointer, nothing stops you writing to what the 
pointer points to, unless that has a const target too. And then you've 
going to have problems doing normal updates. This constness just 
insinuates itself everywhere.


That is not very different from the mutable/immutable concept in Python, 
is it ?
A tuple is immutable, but if it contains a mutable object, nothing 
prevents you from mutating it.

Does it mean you think the mutable/immutable concept of Python is flawed?

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

Re: Lies in education [was Re: The "loop and a half"]

[alister via Python-list]

On Sat, 14 Oct 2017 01:48:44 +1300, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>> I wasn't questioning where the data came from, but how the compiler can
>> write to READ ONLY MEMORY which might not even be in the same continent
>> as the compiler that generated the code.
> 
> I thought it would be fairly obvious that by "put it in read-only
> memory" I meant "arrange for it to be in a location that is read-only at
> run time". Obviously it can't be read-only at *compile* time, just as a
> physical ROM can't be read-only at manufacture time.

oh yes it can
in the past for large quantitys the data in a ROM chip was part of the 
chip etching mask (unless you consider a blank silicon wafer to be 
"Programmable" by the etching process)rather than prom which used 
programmable fuses or prom which could be erased by UV light (assuming 
the chip was fitted with a window otherwise it was known as one time 
programmable EPROM)

The Apollo lunar lander used a magnetic core store that was hard coded at 
the time it was "Woven" 

I doubt that either process is in widespread usage any longer as most 
manufacturers no incorporate a way to update the firmware of a device 
(usually with flash memory)



-- 
"I am not sure what this is, but an `F' would only dignify it."
-- English Professor
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 15:59, Julien Salort wrote:

Le 12/10/2017 à 17:57, bartc a écrit :

With a const struct, you are stopped from directly modifying elements, 
but if an element is a pointer, nothing stops you writing to what the 
pointer points to, unless that has a const target too. And then you've 
going to have problems doing normal updates. This constness just 
insinuates itself everywhere.


That is not very different from the mutable/immutable concept in Python, 
is it ?
A tuple is immutable, but if it contains a mutable object, nothing 
prevents you from mutating it.

Does it mean you think the mutable/immutable concept of Python is flawed?


When you put it like that, then yes!

But it depends on how you define the value of a tuple. If that is a 
recursive definition that includes all nested object levels, then it 
would be harder to keep the whole thing constant.


If you look only one level deep, then it can be fully immutable (never 
mind that some elements could be functions that will give a different 
result each time they are evaluated).



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

EuroPython 2017: Videos for Wednesday available online

[M.-A. Lemburg]

We are pleased to announce the third batch of cut videos for
EuroPython 2017.

To see the new videos, please head over to our EuroPython YouTube
channel and select the “EuroPython 2017″ playlist. The new videos
start at entry 63 in the playlist.


  * EuroPython 2017 Videos *

http://europython.tv/


In the coming two weeks, we will continue to release the other videos
currently marked as “private”, in batches of one conference day per
week.


Enjoy,
--
EuroPython 2017 Team
http://ep2017.europython.eu/
http://www.europython-society.org/

PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/918860053070974976
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:

>> It's just a technique, like greying out certain menu options - clicking
>> them will do nothing, but you won't get an error message and you don't want
>> to allow them anyway, risking more serious consequences.
> 
> Even there, you often CAN get a report about the failure; clicking on
> something that's disabled will cause a short beep, unless that's
> disabled. Maybe you personally don't like that beep, and you'd rather
> it be suppressed - but that's the end user's choice, NOT the
> programmer's. "Errors should never pass silently, unless explicitly
> silenced."

Over 30 years since Apple first put out their user interface guidelines, and
people still get the basics wrong.

"Errors should never pass silently..." is excellent advise for programming,
but not necessarily UIs. With a program, errors in the code represent bugs
that should be fixed, and in principle we can remove the bugs one by one
until there are none left, after which the program will be perfect. (Yeah,
try not to laugh too much.)

But in a UI, that will never be the case. Errors are not bugs, and can't be
removed. All you can do is hope the user doesn't do it again, which they
will. So UIs should follow a slightly different ideal:

"Be tolerant of unimportant errors, and let them pass silently."

For example, pressing delete when there is no text to delete should just
silently do nothing. Why annoy the user by beeping? They probably just held
down the backspace key for a microsecond too long. Surely you wouldn't log
the error: "delete pressed but no text to delete". Um, okay, what do you
expect me to do about it?

Likewise, pressing the left arrow key when you are already at the start of the
text should just silently remain at the start, not chastise the user. Or
clicking in the body of the window where there are no controls or text
fields. (MYOB, I'm looking at you.)

But in fact, clicking a disabled button or menu item is not an error. There's
no need to chastise the user with a beep or by flashing the screen or logging
the event ("warning: user clicked disabled menu").

The point of disabling the menu is to avoid errors by preventing the user from
selecting a command that will fail. The reason the menu is disabled rather
than hidden is to provide a consistent interface and immediate visual
feedback to the user. Clicking a disabled item should simply do nothing at
all.

If, and *only* if, you cannot rely on visual feedback that the item is
disabled (perhaps you're using a text-only interface with no way to visually
distinguish items) then you should provide some other feedback, like a beep
or flashing the screen, or better (since audible feedback is annoying)
display an informational status message that doesn't require explicit
acknowledgement from the user.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:

>> For a novice, seeing 'Segmentation fault (core dumped)' is better?
> 
> Better than silently doing nothing? YES. Absolutely it is.

Chris, you forget that for Bart, his user-base is only himself. If he programs
his home-made system to silently ignore writes to write-protected memory,
that counts as the "...unless explicitly silenced" part of "Errors should
never pass silently...". If that means his software is riddled with bugs, it
will affect only himself, and no novices will be harmed.

But in any case, a seg fault is a pretty crude and dangerous way to report
errors. It isn't so much an error report as the *consequences* of the error,
a bit like your car engine seizing up because you forgot to put oil in it.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

RE: Unable to run pip in Windows 10

[Michael Cuddehe]

Thank you!!!
What finally worked.> py -m pip install pyperclip


-Original Message-
From: Terry Reedy [mailto:tjre...@udel.edu] 
Sent: Wednesday, October 11, 2017 1:00 PM
To: python-list@python.org
Subject: Re: Unable to run pip in Windows 10

On 10/11/2017 10:46 AM, Michael Cuddehe wrote:
> - What exactly did you install?
>>> Latest install: Python 3.5.4 (v3.5.4:3f56838, Aug  8 2017, 02:17:05) [MSC
> v.1900 64 bit (AMD64)] on win32
>>> Downloaded from python.org.
>   - Can you start the Python interpreter?
>>> Yes...works fine.
> * How exactly did you go about this
>>> ??
>   - How exactly do you try to run pip?
>>> Command prompt: c:\Users\FFC>pip import (module)

Try running instead

...> python -m pip install 

or to specifically ensure that you run 3.5,

...> py -3.5 -m pip install 

and if that fails, copy the entire response.

>   - What exactly happens when you try?
>>> Windows error message: "This app can't run on your PC"

-- 
Terry Jan Reedy



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

Re: unorderable types: list() > int()

[Andrew Z]

The answer is:
 The dict returns list - my mistake obviously.

I think list.pop(0) is  better for sanity than list[0]:
 Pos= [k,v for ...].pop(0)



On Oct 13, 2017 00:23, "Andrew Z"  wrote:

> Hello,
> pos = {"CLown":10,"BArbie":20}
> I want to return integer (10) for the keyword that starts with "CL"
>
>
> cl_ = [v for k, v in pos.items() if k.startswith('CL')]
> cl_pos = cl_[0]
> if cl_pos > 0:
>
>blah..
>
>
> There are 2 issues with the above:
>  a. ugly - cl_pos = cl_ [0] .  I was thinking something like
>
>
> cl_ = [v for k, v in pos.items() if k.startswith('CL')][0]
>
>   but that is too much for the eyes - in 2 weeks i'll rewrite this into
> something i can understand without banging against the desk.
> So what can be a better approach here ?
>
>
> b. in "cl_pos > 0:, cl_pos apparently is still a list. Though the run in a
> python console has no issues and report cl_pos as int.
>
>
> Appreciate.
>
>
>
>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 16:33, Steve D'Aprano wrote:

On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:


For a novice, seeing 'Segmentation fault (core dumped)' is better?


Better than silently doing nothing? YES. Absolutely it is.


Chris, you forget that for Bart, his user-base is only himself. If he programs
his home-made system to silently ignore writes to write-protected memory,
that counts as the "...unless explicitly silenced" part of "Errors should
never pass silently...". If that means his software is riddled with bugs, it
will affect only himself, and no novices will be harmed.


You're making light of a scheme that was extremely effective in a 
computer system with otherwise unprotected memory, that could write 
anywhere, including over all the code and over the OS.


Without that write protection, what would have happened? Either it would 
go completely haywire, or hang, or could subtly change resident programs 
in dangerous ways.


Or I could put that switch in then I could be CERTAIN that essential 
programs and data were untouched no matter what happened.


So if it worked well then without needing to abort and report a message, 
why can't a scheme like that work now?


BTW, when you're developing a new bit of hardware or software, and 
you're not part of team, then the user-base is normally just yourself. 
Nothing wrong with that, but you seem to like belittling people with 
such comments. What was the userbase when GvR started Python?


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

Re: Lies in education [was Re: The "loop and a half"]

[Marko Rauhamaa]

alister :

> On Sat, 14 Oct 2017 01:48:44 +1300, Gregory Ewing wrote:
>> I thought it would be fairly obvious that by "put it in read-only
>> memory" I meant "arrange for it to be in a location that is read-only
>> at run time". Obviously it can't be read-only at *compile* time, just
>> as a physical ROM can't be read-only at manufacture time.
>
> oh yes it can
> [...]
>
> I doubt that either process is in widespread usage any longer as most 
> manufacturers no incorporate a way to update the firmware of a device 
> (usually with flash memory)

Then there's the case of FPGA, which can expose parts of itself as
memory, whether writable or read-only. You can reprogram its ROM (and
other) parts, but not using the regular RAM write mechanisms.

In general, memory-mapped I/O may be read-only to software. For example,
you could read dip-switch settings or the error counts of a hard disk
from "const volatile" memory areas. There, "const" means you can't write
into it and "volatile" means it could change "by itself".


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

Re: Python-list Digest, Vol 169, Issue 23

[Steve D'Aprano]

Hi Roger,

Unfortunately you seem to have messed up the quoting (*and* the subject line,
and the threading) for this post. The perils of replying to digests.

I'll try to repair the worst of the misquoted text as I go, but if I
accidentally attribute something I said to you, well, that's only because you
did so first :-)


On Fri, 13 Oct 2017 02:53 am, ROGER GRAYDON CHRISTMAN wrote:

> On Thu, Oct 12, 2017 08:05 AM, Steve D'Aprano wrote:>

[...]

> This seems like a veritable straw man if any.
> I am fairly sure that "one entry, one exit"
> does not precisely mean "no branching whatsoever"
> Nor does discouraging unrestricted GOTO
> suggest that either.


But Meyer doesn't just prohibit unrestricted GOTO. He prohibits, quote:

'any "break" or similar control mechanism.'

Similar control mechanisms include *anything that branches*: they all have in
common the fact that they branch, and that they jump from one executable
statement to another, potentially far distant statement, rather than executing
the next statement unconditionally.

Now, you would be right that I was straw-manning *if* I had argued that:

"Meyer is wrong because he wishes to prohibit `if` and `for` 
and function calls."

But that is not even close to what I said: paraphrasing slightly, I said that
if we take Meyer literally, that is what would be prohibited, but surely
Meyer does not intend us to take him literally. That would be unreasonable.
Therefore we must infer that Meyer breaks up branching control mechanisms
into at least two groups:

- those which are allowed, such as (we must presume) function calls,
  exceptions, loops, `if...else`;

- those which are not allowed, such as `break`.

The only concrete example of a bad form of jump that he gives is `break`, so
we are left to guess at where he draws the line. I made a conservative,
reasonable guess that he would want to allow subroutine calls, looping and
conditional jumps (`if...else`).

So what I did was the *literal opposite* of a straw man: I took a statement
which is, on the face of it, obviously wrong, and strengthened it to something
much more reasonable and defensible.

Setting aside the (likely?) possibility that Meyer clarified his intention in
the book, if we judge his position on his quoted words alone, then we must
conclude that he wishes to prohibit any branching operation:

- he doesn't refer to "unrestricted goto", but to unqualified "goto";

- the one concrete example he gives, "break", is an extremely restricted
  form of goto: you can only use it to jump from inside a loop to the
  first instruction immediately outside of the loop.

As jumps go, you can't get much more restricted than "break", and yet Meyer is
still against it. Judging Meyer's *actual* words, rather than putting words
into his mouth, his position is more unreasonable and even weaker than the
one I argue against.

Hence, the very opposite of a straw man: I am arguing against an iron man, a
position stronger than the one Meyer expressed.

(One of my pet peeves is people misusing "straw man", but I must say this is
the most blatantly wrong example I've seen.)

My argument is that `break` and `continue` do not belong in the "bad list" of
jumps that should be prohibited, not that Meyer thinks that we shouldn't use
subroutines. See further below.

Ironically, the one concrete example (that Stefan quotes) of what Meyer
considers to be an allowed jump is exception handling, which many people
discourage because of its similarity to GOTO or COMEFROM:

"I consider exceptions to be no better than “goto’s”, considered 
harmful since the 1960s, in that they create an abrupt jump 
from one point of code to another."

https://www.joelonsoftware.com/2003/10/13/13/

"The core problem is the hidden control-flow possibility. [...]
Exception handling introduces precisely this kind of hidden
control flow possibility, at nearly every significant line
of code"

http://www.lighterra.com/papers/exceptionsharmful/

"Goto statements went out of style in the 60s, relegated today
to be the prototypical example of bad coding. Yet hardly
anyone seems to be bothered by exceptions, which do basically
the same thing."

https://petercai.com/the-case-against-exceptions/

Raymond Chen has written on why exceptions are hard to get right:

https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=39683/

https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693/

and of course when Rob Pike created Go, he famously left exceptions out of the
language, almost uniquely for a 21st century language.

So the irony here is that Meyer wishes to prohibit the *least harmful* and
*most defensible* form of restricted jump outside of the if/while/for
statements, namely the "break" statement; while he would allow one of the
more confusing, heavily-criticised, least-restricted jumps still allowed in
modern languages (exceptions).

In a language with exceptions, every method,

Re: Lies in education [was Re: The "loop and a half"]

[ROGER GRAYDON CHRISTMAN]

On Sat, Oct 14, 2017, Gregory Ewing wrote:
>
Message: 5
>Date: Sat, 14 Oct 2017 01:54:49 +1300
>From: Gregory Ewing 
>To: python-list@python.org
>Subject: Re: Lies in education [was Re: The "loop and a half"]
>Message-ID: 
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Neil Cerutti wrote:
>> I can tell at a glance if a parameter is expected to be
>> modifiable just by looking at the function signature.
>
>The question is why doesn't anyone feel the need to be
>able to do that for Python functions? Whether a function
>modifies things passed to it is just as important to
>know in Python as it is in C.
>


I'm just trying to put myself in the position of the programmer
who is in this position of identifying the modifiable parameters
in the function signature.

Where are you getting the function signature?

Are you looking at the source code?   Or from the help() that access the module?

In both cases, the docstring is an easy solution.
The documentation itself in certainly state whether it modifies any parameter.
And it is directly visible along with the function signature either way.

We don't need any annotations or attributes or whatnot if we have
the perfectly normal function documentation.

Or is that kind of habit no longer practiced in 'the real world'?

Roger Christman
Pennsylvania State University


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

Re: Lies in education [was Re: The "loop and a half"]

[Neil Cerutti]

On 2017-10-13, Steve D'Aprano  wrote:
> On Fri, 13 Oct 2017 11:54 pm, Gregory Ewing wrote:
>
>> Neil Cerutti wrote:
>>> I can tell at a glance if a parameter is expected to be
>>> modifiable just by looking at the function signature.
>> 
>> The question is why doesn't anyone feel the need to be
>> able to do that for Python functions? Whether a function
>> modifies things passed to it is just as important to
>> know in Python as it is in C.
>
> Lots of people would like Python to have a "freeze" function
> that can make immutable objects, it is a moderately common
> feature request.
>
> Some people (myself included) would like a "const" declaration
> that gives us names that can only be bound to once:
>
> const spam = "NOBODY expects the Spanish Inquisition!!!"  #
> Okay spam = "foo"  # Error.
>
> I don't mind if that is a runtime error, although a compile
> time error would be nicer.

When there are many constants I tend to create a class called
Constant that either doesn't get instanced, or has only one
instance (sometimes some of my constants need to be calculated
once at runtime).

> I don't know if either of these (actual immutable pure-Python
> objects, and un-rebindable names) count as quite the same thing
> you are asking Neil about. But I trust they're related.

Looking at the Python functions I actually write today, I've
evolved my style until I simply don't modify function arguments,
so it matters not if parameters are declared const.

But my oldest programs still in use are different. For example:

records = defaultdict(Data)
read_unmatched_records(records)

And then later code continues screwing around with that
dictionary and liberally using C-style constant names, e.g.:

for fname in glob.glob(COUNSELING_ACK):
process_counseling_acks(fname, records)
for fname in glob.glob(PLUS_APP_ACK):
process_plus_request(fname, records)

Such code feels alien to me now. A small script for reading
promissory note acknowledgements grew into a business-vital,
1,000 LOC octopus without my leave.

-- 
Neil Cerutti

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

Re: Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 14:51, Chris Angelico  wrote:
> On Sat, Oct 14, 2017 at 1:32 AM, Steve D'Aprano
> wrote:
>> It seems to me that you're not talking about ROM at all, but ordinary RAM.
>> Then what do you mean by "read only"? A block of memory with a flag that
>> says "unprivileged processes are prohibited from writing here"?
>>
>> (That's also not a rhetorical question.)
>
> When I first learned about Protected Mode (as defined by the Intel
> 80386 and used in OS/2), there was a real concept of read-only RAM.
> The program loader would fetch up the executable file (data on the
> disk) and construct its segments: code, data, and BSS/stack.

This is still the case. The granularity is just finer now: Instead of
segments you use pages. (The 386 was the first x86 processor which
supported paging. OS/2 probably used segments because it was originally
designed for the 286.)

hp


-- 
   _  | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| |   | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 15:28, Steve D'Aprano  wrote:
> On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:
>>> It's just a technique, like greying out certain menu options - clicking
>>> them will do nothing, but you won't get an error message and you don't want
>>> to allow them anyway, risking more serious consequences.
>> 
>> Even there, you often CAN get a report about the failure; clicking on
>> something that's disabled will cause a short beep, unless that's
>> disabled. Maybe you personally don't like that beep, and you'd rather
>> it be suppressed - but that's the end user's choice, NOT the
>> programmer's. "Errors should never pass silently, unless explicitly
>> silenced."
>
> Over 30 years since Apple first put out their user interface guidelines, and
> people still get the basics wrong.
>
> "Errors should never pass silently..." is excellent advise for programming,
> but not necessarily UIs. With a program, errors in the code represent bugs
> that should be fixed, and in principle we can remove the bugs one by one
> until there are none left, after which the program will be perfect. (Yeah,
> try not to laugh too much.)
>
> But in a UI, that will never be the case. Errors are not bugs, and can't be
> removed.

It is also not a bug if - for example - a file cannot be opened, or is
malformed. But you have to tell the user what went wrong. Pretending
that all went well won't make the user happy (or at least that happyness
will be short-lived).

> All you can do is hope the user doesn't do it again, which they
> will. So UIs should follow a slightly different ideal:
>
> "Be tolerant of unimportant errors, and let them pass silently."
[...]
> Likewise, pressing the left arrow key when you are already at the start of the
> text should just silently remain at the start, not chastise the user.
[... other examples elided ...]
> But in fact, clicking a disabled button or menu item is not an error.

If it is not an error, clearly the rule does not apply. So it depends on
whether the action is an error or not (actually in the case of the
disabled button I would tend to think it is an error: I can't think of a
reason why anybody would intentionally click on a disabled button[1]).

Pressing the left arrow key when you are already at the start of the
line is good example. The user might expect the cursor to jump the end
of the previous line, so if your program doesn't do that you probably
should give some feedback. Or the user might just have pressed the key a
bit too long, then the cursor should just stop there ("vi has two modes:
One beeps a lot and the other doesn't"). So it depends on what the user
expects. I think Chris a very good point here that this should be
configurable unless your user base is very homogenous.

hp

[1] Except in a demo: "As you can see, this button is now disabled.
Nothing happens when I click on it!" Everbody dives under the table
just in time before the espresso machine in the corner explodes.

-- 
   _  | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| |   | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[Chris Angelico]

On Sat, Oct 14, 2017 at 6:32 AM, Peter J. Holzer  wrote:
> On 2017-10-13 14:51, Chris Angelico  wrote:
>> On Sat, Oct 14, 2017 at 1:32 AM, Steve D'Aprano
>> wrote:
>>> It seems to me that you're not talking about ROM at all, but ordinary RAM.
>>> Then what do you mean by "read only"? A block of memory with a flag that
>>> says "unprivileged processes are prohibited from writing here"?
>>>
>>> (That's also not a rhetorical question.)
>>
>> When I first learned about Protected Mode (as defined by the Intel
>> 80386 and used in OS/2), there was a real concept of read-only RAM.
>> The program loader would fetch up the executable file (data on the
>> disk) and construct its segments: code, data, and BSS/stack.
>
> This is still the case. The granularity is just finer now: Instead of
> segments you use pages. (The 386 was the first x86 processor which
> supported paging. OS/2 probably used segments because it was originally
> designed for the 286.)

... either that, or I'm just misremembering, it being many MANY years
since I did anything that low-level. Let's assume I was mistaken. :)

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

Re: Lies in education [was Re: The "loop and a half"]

[Peter J. Holzer]

On 2017-10-13 15:11, alister  wrote:
> On Sat, 14 Oct 2017 01:48:44 +1300, Gregory Ewing wrote:
>> Steve D'Aprano wrote:
>>> I wasn't questioning where the data came from, but how the compiler can
>>> write to READ ONLY MEMORY which might not even be in the same continent
>>> as the compiler that generated the code.
>> 
>> I thought it would be fairly obvious that by "put it in read-only
>> memory" I meant "arrange for it to be in a location that is read-only at
>> run time". Obviously it can't be read-only at *compile* time, just as a
>> physical ROM can't be read-only at manufacture time.
>
> oh yes it can
> in the past for large quantitys the data in a ROM chip was part of the 
> chip etching mask (unless you consider a blank silicon wafer to be 
> "Programmable" by the etching process)rather than prom which used 
> programmable fuses or prom which could be erased by UV light (assuming 
> the chip was fitted with a window otherwise it was known as one time 
> programmable EPROM)

He didn't say "programmable". He said that the is "not read-only".
Obviously the wafer is modified during the etching process and
afterwards it contains information it didn't before. Would you say a
piece of paper is "read-only" because you can't program it using address
and data lines? I can write on it, I just need a different tool.

hp


-- 
   _  | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| |   | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[bartc]

On 13/10/2017 15:39, Steve D'Aprano wrote:

On Fri, 13 Oct 2017 11:54 pm, Gregory Ewing wrote:


Neil Cerutti wrote:

I can tell at a glance if a parameter is expected to be
modifiable just by looking at the function signature.


The question is why doesn't anyone feel the need to be
able to do that for Python functions? Whether a function
modifies things passed to it is just as important to
know in Python as it is in C.


Lots of people would like Python to have a "freeze" function that can make
immutable objects, it is a moderately common feature request.

Some people (myself included) would like a "const" declaration that gives us
names that can only be bound to once:

const spam = "NOBODY expects the Spanish Inquisition!!!"  # Okay
spam = "foo"  # Error.


Presumably also:

const def f:
const class c:
const import i



I don't mind if that is a runtime error, although a compile time error would
be nicer.


This would be of most use when the byte-code compiler (assuming there is 
one) knows about them. But many will be inside imported modules whose 
contents, AIUI, are not visible to the byte-code compiler.


And then they would be accessed as:

  i.spam

So this would be a const attribute.

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

Re: Running flask on AWS SAM

[Frustrated learner]

Any takers?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Heroku (was Re: Lies in education [was Re: The "loop and a half"])

[Ben Bacarisse]

Chris Angelico  writes:

> On Fri, Oct 13, 2017 at 10:14 AM, Ben Bacarisse  wrote:
>> Chris Angelico  writes:
>>> I abbreviated that down to nothing, but since you ask, here's a really
>>> REALLY simple run-down of how to use Heroku:
>>
>> I think I see what you mean now.  You meant no configuration is needed
>> because you use (or buy?) a cloud service that's all set up for it
>> already?
>
> Correct - because the setup needed is completely generic.
>
>> From this and other posts I think the position is that I do need to do
>> some server configuration (and essentially install a proxy server) to
>> run Python web applications on my typical Apache set-up.  And I would
>> then have to shop around for suitable hosting that is already set up for
>> running them.
>>
>> 
>>
>> Thanks.  That's not quite what I was after but it's good to know how to
>> do that should I want to that later.
>
> Yep, it's not too hard.
>
> And that's why it's cleaner to work with Python than PHP. To use
> custom URL routing in PHP, you have to use custom server rules; to use
> custom URL routing in Python, you use  "@app.route(...)" lines inside
> your app, and perfectly standard server rules.

That's one way to put it.  Another is that to use Python I need to buy a
new service that is already configured.  If that's the way it's done,
fine, but this sub-thread started with someone being surprised by the
success of PHP.

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

Re: Heroku (was Re: Lies in education [was Re: The "loop and a half"])

[Chris Angelico]

On Sat, Oct 14, 2017 at 8:42 AM, Ben Bacarisse  wrote:
> Chris Angelico  writes:
>
>> On Fri, Oct 13, 2017 at 10:14 AM, Ben Bacarisse  wrote:
>>> Chris Angelico  writes:
 I abbreviated that down to nothing, but since you ask, here's a really
 REALLY simple run-down of how to use Heroku:
>>>
>>> I think I see what you mean now.  You meant no configuration is needed
>>> because you use (or buy?) a cloud service that's all set up for it
>>> already?
>>
>> Correct - because the setup needed is completely generic.
>>
>>> From this and other posts I think the position is that I do need to do
>>> some server configuration (and essentially install a proxy server) to
>>> run Python web applications on my typical Apache set-up.  And I would
>>> then have to shop around for suitable hosting that is already set up for
>>> running them.
>>>
>>> 
>>>
>>> Thanks.  That's not quite what I was after but it's good to know how to
>>> do that should I want to that later.
>>
>> Yep, it's not too hard.
>>
>> And that's why it's cleaner to work with Python than PHP. To use
>> custom URL routing in PHP, you have to use custom server rules; to use
>> custom URL routing in Python, you use  "@app.route(...)" lines inside
>> your app, and perfectly standard server rules.
>
> That's one way to put it.  Another is that to use Python I need to buy a
> new service that is already configured.  If that's the way it's done,
> fine, but this sub-thread started with someone being surprised by the
> success of PHP.

Thing is, that's exactly the same for both languages these days. You
can get cheap (even zero-dollar) hosting that's preconfigured to be
able to support either. There USED to be a difference, and everyone's
acknowledged this - PHP built up some inertia - but there's now no
real reason for it other than "it's popular, therefore people use it".

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

Re: Heroku (was Re: Lies in education [was Re: The "loop and a half"])

[Grant Edwards]

On 2017-10-13, Chris Angelico  wrote:

[regarding PHP vs Python capable web-hosting services]

> Thing is, that's exactly the same for both languages these days. You
> can get cheap (even zero-dollar) hosting that's preconfigured to be
> able to support either. There USED to be a difference, and everyone's
> acknowledged this - PHP built up some inertia - but there's now no
> real reason for it other than "it's popular, therefore people use it".

Well, it's said that suffering builds character...

What they don't tell you is what sort of character.
-- 
Grant Edwards   grant.b.edwardsYow! Am I SHOPLIFTING?
  at   
  gmail.com

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

Re: Heroku (was Re: Lies in education [was Re: The "loop and a half"])

[Chris Angelico]

On Sat, Oct 14, 2017 at 9:02 AM, Grant Edwards
 wrote:
> On 2017-10-13, Chris Angelico  wrote:
>
> [regarding PHP vs Python capable web-hosting services]
>
>> Thing is, that's exactly the same for both languages these days. You
>> can get cheap (even zero-dollar) hosting that's preconfigured to be
>> able to support either. There USED to be a difference, and everyone's
>> acknowledged this - PHP built up some inertia - but there's now no
>> real reason for it other than "it's popular, therefore people use it".
>
> Well, it's said that suffering builds character...
>
> What they don't tell you is what sort of character.

I think it mostly builds U+1F4A9.

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

Re: Running flask on AWS SAM

[sohcahtoa82]

On Thursday, October 12, 2017 at 9:20:11 PM UTC-7, Frustrated learner wrote:
> Hello,
> 
> I have a flask based application which i am able to run locally.
> 
> $ python swagger_server/app.py 
>  * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
> 
> I am trying to port this over to aws. I have all the dependencies and code 
> organized in the same folder.
> 
> Here is the transaction and error:
> $ SERVER_NAME=0.0.0.0:3000 sam local start-api 
> 2017/10/12 21:02:20 Connected to Docker 1.32
> 2017/10/12 21:02:20 Fetching lambci/lambda:python3.6 image for python3.6 
> runtime...
> python3.6: Pulling from lambci/lambda
> Digest: 
> sha256:c77ea3986c471c2f93dfa2a86492e6306989505073795da3b22defa2b10846a6
> Status: Image is up to date for lambci/lambda:python3.6
> 
> Mounting swagger_server.app.app (python3.6) at http://127.0.0.1:3000/current 
> [GET]
> Mounting static files from public at /
> 
> You can now browse to the above endpoints to invoke your functions.
> You do not need to restart/reload SAM CLI while working on your functions,
> changes will be reflected instantly/automatically. You only need to restart
> SAM CLI if you update your AWS SAM template.
> 
> 2017/10/12 21:02:30 Invoking swagger_server.app.app (python3.6)
> 2017/10/12 21:02:30 Decompressing 
> /Users/shekartippur/playground/cyclopscloud/cyclopsglobal/swagger_server.zip
> START RequestId: 9518afce-6cf7-4f20-9a31-0a60907b5467 Version: $LATEST
> 'SERVER_NAME': KeyError
> Traceback (most recent call last):
>   File "/var/task/connexion/apps/abstract.py", line 266, in __call__
> return self.app(environ, start_response)
>   File "/var/task/flask/app.py", line 1997, in __call__
> return self.wsgi_app(environ, start_response)
>   File "/var/task/flask/app.py", line 1977, in wsgi_app
> ctx = self.request_context(environ)
>   File "/var/task/flask/app.py", line 1938, in request_context
> return RequestContext(self, environ)
>   File "/var/task/flask/ctx.py", line 242, in __init__
> self.url_adapter = app.create_url_adapter(self.request)
>   File "/var/task/flask/app.py", line 1765, in create_url_adapter
> server_name=self.config['SERVER_NAME'])
>   File "/var/task/werkzeug/routing.py", line 1299, in bind_to_environ
> wsgi_server_name = environ['SERVER_NAME']
> KeyError: 'SERVER_NAME'
> 
> END RequestId: 9518afce-6cf7-4f20-9a31-0a60907b5467
> REPORT RequestId: 9518afce-6cf7-4f20-9a31-0a60907b5467 Duration: 3257 ms 
> Billed Duration: 3300 ms Memory Size: 0 MB Max Memory Used: 38 MB
> 
> I looked up the error and dint find much help. Wondering what I could be 
> missing.

Instead of doing:

SERVER_NAME=0.0.0.0:3000 sam local start-api 

try this:

export SERVER_NAME="0.0.0.0:3000 sam local start-api"
-- 
https://mail.python.org/mailman/listinfo/python-list

Python 2 -> 3, urllib.urlOpen

[Irv Kalb]

One of the colleges where I teach has just moved from Python 2 to Python 3.  I 
am in the process of converting my beginning Python class from Python 2 to 
Python 3.  Everything has gone smoothly, until I just tried to convert some 
code that imports and uses urllib.urlOpen to fetch data through an API.  I am 
using an API that I found here:http://www.jarloo.com/yahoo_finance/ 


As a minimal example, I am trying to get the latest stock price for Apple.  

The following example works perfectly in Python 2:

import urllib

# set the Yahoo finance url, set stock name, ask for last price
fullURLWithParameters = 'http://finance.yahoo.com/d/quotes.csv?s=aapl&f=l1'

# read all the data
response = urllib.urlopen(fullURLWithParameters).read()

print 'Response is: ', response

This is asking for a stock name (s=) and I am adding in aapl as a stock symbol. 
 I am also adding a "flag" parameter (f=) and setting it to l1 to get the last 
trade price.  When I run this in Python 2, I see:

Response is:  156.99


If I take the same program and just modify the print statement to add 
parentheses, then try to run it in Python 3.6 (on a Mac):


import urllib

# set the Yahoo finance url, set stock name, ask for last price
fullURLWithParameters = 'http://finance.yahoo.com/d/quotes.csv?s=aapl&f=l1'

# read all the data
response = urllib.urlopen(fullURLWithParameters).read()

print('Response is: ', response)

I get the following:

Traceback (most recent call last):
  File "   s/StockQuoteYahooAPIMinimal.py", line 9, in 
response = urllib.urlopen(fullURLWithParameters).read()
AttributeError: module 'urllib' has no attribute 'urlopen'


I've looked at the Python 3.6 documentation for urllib, and I see that certain 
calls have been changed and others have been eliminated.  But my eyes glaze 
over trying to figure out what to use instead.

My question is: Is there a simple (hopefully one or two line) replacement for 
my call to url lib.urlopen().read()

I know that there are other modules out there that handle requests (like the 
Requests module), but this is a strictly controlled university environment.  I 
cannot download any external packages (other then pygame, which I got special 
permission for) onto the computers in the school.  Therefore, I'm looking for 
something in the Python 3.6 Standard Library.  

Thanks in advance,

Irv

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

Re: Python 2 -> 3, urllib.urlOpen

[boB Stepp]

On Fri, Oct 13, 2017 at 5:27 PM, Irv Kalb  wrote:

> I've looked at the Python 3.6 documentation for urllib, and I see that 
> certain calls have been changed and others have been eliminated.  But my eyes 
> glaze over trying to figure out what to use instead.
>
> My question is: Is there a simple (hopefully one or two line) replacement for 
> my call to url lib.urlopen().read()

I don't know much about this, but might you be looking for
urllib.request.urlopen()?  See

https://docs.python.org/3/library/urllib.request.html#module-urllib.request

in the docs.

> I know that there are other modules out there that handle requests (like the 
> Requests module), but this is a strictly controlled university environment.  
> I cannot download any external packages (other then pygame, which I got 
> special permission for) onto the computers in the school.  Therefore, I'm 
> looking for something in the Python 3.6 Standard Library.

The above is in the standard library.
-- 
boB
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Heroku (was Re: Lies in education [was Re: The "loop and a half"])

[Ben Bacarisse]

Chris Angelico  writes:

> On Sat, Oct 14, 2017 at 8:42 AM, Ben Bacarisse  wrote:
>> Chris Angelico  writes:
>>
>>> On Fri, Oct 13, 2017 at 10:14 AM, Ben Bacarisse  
>>> wrote:
 Chris Angelico  writes:
> I abbreviated that down to nothing, but since you ask, here's a really
> REALLY simple run-down of how to use Heroku:

 I think I see what you mean now.  You meant no configuration is needed
 because you use (or buy?) a cloud service that's all set up for it
 already?
>>>
>>> Correct - because the setup needed is completely generic.
>>>
 From this and other posts I think the position is that I do need to do
 some server configuration (and essentially install a proxy server) to
 run Python web applications on my typical Apache set-up.  And I would
 then have to shop around for suitable hosting that is already set up for
 running them.

 

 Thanks.  That's not quite what I was after but it's good to know how to
 do that should I want to that later.
>>>
>>> Yep, it's not too hard.
>>>
>>> And that's why it's cleaner to work with Python than PHP. To use
>>> custom URL routing in PHP, you have to use custom server rules; to use
>>> custom URL routing in Python, you use  "@app.route(...)" lines inside
>>> your app, and perfectly standard server rules.
>>
>> That's one way to put it.  Another is that to use Python I need to buy a
>> new service that is already configured.  If that's the way it's done,
>> fine, but this sub-thread started with someone being surprised by the
>> success of PHP.
>
> Thing is, that's exactly the same for both languages these days. You
> can get cheap (even zero-dollar) hosting that's preconfigured to be
> able to support either. There USED to be a difference, and everyone's
> acknowledged this - PHP built up some inertia - but there's now no
> real reason for it other than "it's popular, therefore people use it".

That's good to know, but of course the current success of PHP is based
exactly on what used to be the case.  It will take a while for the
inherent inertia of people, skills, processes and so on to be overcome.

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

Re: Python 2 -> 3, urllib.urlOpen

[Thomas Jollans]

On 14/10/17 00:27, Irv Kalb wrote:
> One of the colleges where I teach has just moved from Python 2 to Python 3.  
> I am in the process of converting my beginning Python class from Python 2 to 
> Python 3.  Everything has gone smoothly, until I just tried to convert some 
> code that imports and uses urllib.urlOpen to fetch data through an API.  I am 
> using an API that I found here:http://www.jarloo.com/yahoo_finance/ 
> 
> 

Hi Irv,

That's great! It's always nice to hear about more people moving with the
times :-)

> [...]
>
> Traceback (most recent call last):
>   File "   s/StockQuoteYahooAPIMinimal.py", line 9, in 
> response = urllib.urlopen(fullURLWithParameters).read()
> AttributeError: module 'urllib' has no attribute 'urlopen'
> 
> 
> I've looked at the Python 3.6 documentation for urllib, and I see that 
> certain calls have been changed and others have been eliminated.  But my eyes 
> glaze over trying to figure out what to use instead.
> 
> My question is: Is there a simple (hopefully one or two line) replacement for 
> my call to url lib.urlopen().read()

Python 3 changed a number of things, including some rearrangement of the
standard library. The "What's new in Python 3.x" documents are always
worth reading, but I think you'll find "What's new in Python 3.0"
particularly useful. 

The library changes are specified in PEP 3108 (this is linked from the
"What's new" document) 

Python 3 has the urllib.request.urlopen function

- this is descended from Python 2's urllib2.urlopen, and should be
exactly what you need.

> 
> I know that there are other modules out there that handle requests (like the 
> Requests module), but this is a strictly controlled university environment.  
> I cannot download any external packages (other then pygame, which I got 
> special permission for) onto the computers in the school.  Therefore, I'm 
> looking for something in the Python 3.6 Standard Library.  

It's nice that Python comes with batteries included, isn't it?


Cheers,
Thomas


PS: Pay attention to the fact that Python is case sensitive, and the
function called urlopen (like in your code) and not urlOpen (like in
your subject line)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[Gregory Ewing]

Steve D'Aprano wrote:

For example, pressing delete when there is no text to delete should just
silently do nothing.


That's really just a matter of deciding what should count as
an error and what shouldn't. You've decided that "pressing
Delete when there's nothing to delete does nothing" is a
reasonable thing to include in the specifications of correct
behaviour for the program.

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

Re: Lies in education [was Re: The "loop and a half"]

[Gregory Ewing]

alister wrote:
in the past for large quantitys the data in a ROM chip was part of the 
chip etching mask


I know, I'm considering the masking process to be a kind of
write operation.

The Apollo lunar lander used a magnetic core store that was hard coded at 
the time it was "Woven" 

I doubt that either process is in widespread usage any longer as most 
manufacturers no incorporate a way to update the firmware of a device


Magnetic core technology died out long before that, due to
inability to build machines that simulated armies of ladies
with sewing needles!

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

Re: Case Solution: Bratwurst, Beer and Business Planning for Growth at Wurstküche by Thomas Knapp, Jacqueline Orr

[farjanaumme1]

On Thursday, July 27, 2017 at 9:01:17 PM UTC+10, Case Solution & Analysis wrote:
> Case Solution and Analysis of Bratwurst, Beer and Business: Planning for 
> Growth at Wurstküche by Thomas Knapp, Jacqueline Orr is available at a lowest 
> price, send email to casesolutionscentre(at)gmail(dot)com if you want to 
> order the Case Solution. 
> 
> Case Study ID: SCG526 
> 
> Get Case Study Solution and Analysis of Bratwurst, Beer and Business: 
> Planning for Growth at Wurstküche in a FAIR PRICE!! 
> 
> Our e-mail address is CASESOLUTIONSCENTRE (AT) GMAIL (DOT) COM. Please 
> replace (at) by @ and (dot) by . 
> 
> YOU MUST WRITE THE FOLLOWING WHILE PLACING YOUR ORDER: 
> Complete Case Study Name 
> Authors 
> Case Study ID 
> Publisher of Case Study 
> Your Requirements / Case Questions 
> 
> Note: Do not REPLY to this post because we do not reply to posts here. If you 
> need any Case Solution please send us an email. We can help you to get it.

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

Re: Python 2 -> 3, urllib.urlOpen

[MRAB]

On 2017-10-13 23:27, Irv Kalb wrote:

One of the colleges where I teach has just moved from Python 2 to Python 3.  I am in 
the process of converting my beginning Python class from Python 2 to Python 3.  
Everything has gone smoothly, until I just tried to convert some code that imports 
and uses urllib.urlOpen to fetch data through an API.  I am using an API that I found 
here:http://www.jarloo.com/yahoo_finance/ 


As a minimal example, I am trying to get the latest stock price for Apple.

The following example works perfectly in Python 2:

import urllib

# set the Yahoo finance url, set stock name, ask for last price
fullURLWithParameters = 'http://finance.yahoo.com/d/quotes.csv?s=aapl&f=l1'

# read all the data
response = urllib.urlopen(fullURLWithParameters).read()

print 'Response is: ', response

This is asking for a stock name (s=) and I am adding in aapl as a stock symbol.  I am 
also adding a "flag" parameter (f=) and setting it to l1 to get the last trade 
price.  When I run this in Python 2, I see:

Response is:  156.99


If I take the same program and just modify the print statement to add 
parentheses, then try to run it in Python 3.6 (on a Mac):


import urllib

# set the Yahoo finance url, set stock name, ask for last price
fullURLWithParameters = 'http://finance.yahoo.com/d/quotes.csv?s=aapl&f=l1'

# read all the data
response = urllib.urlopen(fullURLWithParameters).read()

print('Response is: ', response)

I get the following:

Traceback (most recent call last):
   File "   s/StockQuoteYahooAPIMinimal.py", line 9, in 
 response = urllib.urlopen(fullURLWithParameters).read()
AttributeError: module 'urllib' has no attribute 'urlopen'


I've looked at the Python 3.6 documentation for urllib, and I see that certain 
calls have been changed and others have been eliminated.  But my eyes glaze 
over trying to figure out what to use instead.

My question is: Is there a simple (hopefully one or two line) replacement for my call 
to url lib.urlopen().read()

I know that there are other modules out there that handle requests (like the 
Requests module), but this is a strictly controlled university environment.  I 
cannot download any external packages (other then pygame, which I got special 
permission for) onto the computers in the school.  Therefore, I'm looking for 
something in the Python 3.6 Standard Library.


Try:

from urllib import request
response = request.urlopen(fullURLWithParameters).read()

Note that the response is bytes.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Sat, 14 Oct 2017 07:15 am, Peter J. Holzer wrote:

> On 2017-10-13 15:11, alister  wrote:
>> On Sat, 14 Oct 2017 01:48:44 +1300, Gregory Ewing wrote:
>>> Steve D'Aprano wrote:
 I wasn't questioning where the data came from, but how the compiler can
 write to READ ONLY MEMORY which might not even be in the same continent
 as the compiler that generated the code.
>>> 
>>> I thought it would be fairly obvious that by "put it in read-only
>>> memory" I meant "arrange for it to be in a location that is read-only at
>>> run time". Obviously it can't be read-only at *compile* time, just as a
>>> physical ROM can't be read-only at manufacture time.
>>
>> oh yes it can
>> in the past for large quantitys the data in a ROM chip was part of the
>> chip etching mask (unless you consider a blank silicon wafer to be
>> "Programmable" by the etching process)rather than prom which used
>> programmable fuses or prom which could be erased by UV light (assuming
>> the chip was fitted with a window otherwise it was known as one time
>> programmable EPROM)
> 
> He didn't say "programmable". He said that the is "not read-only".

In context, we are talking about a computer program (the compiler) writing
data to memory. When we talk about programs writing data to memory, only
certain types of actions are included, and a distant factory etching silicon
chips is not usually one of them.

The question is, does the process of manufacturing a silicon chip count as
*writing*? I don't think so. Not every side-effect should be described as
writing: if the compiler's output was fed into a robot that used it to
assemble a car, I'm sure you would not want to say that the compiler wrote a
car. That would be a misuse of language. I think the idea of writing a ROM
chip is equally a misuse of language.

Your example of writing on paper is a good one, but it argues *against* your
position, not for it. If you compile some code, then take a hex dump and
print it out:

gcc program.c
xxd a.out | lp

would you describe the process as "the compiler writes to the piece of paper"?

I don't think that is justified. The compiler isn't writing to the paper, the
printer is printing to the paper. I would accept the description "lp writes
to the printer", but that's as far as it goes.

Instead of using a printer, perhaps you pipe the output to less and then spend
the next hour laboriously hand-writing the hex dump out. (Perhaps you lost a
bet, or you are playing a game of Truth Or Dare.) Do you still want to claim
that the compiler did the writing?

If you email the hex dump to a person on the other side of the world, who then
post-processes the file in some unknown fashion, and passes the processed
file to another machine, which uses that as input to an industrial process
which etches wafers of silicon and manufacturers a ROM chip, do you still
think it is reasonable to describe it as the *compiler* doing *writing*?

I maintain the choice of words is wrong on both counts: the compiler is not
the entity doing the work, and the work of manufacturing a ROM chip should
not be described as writing.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Sat, 14 Oct 2017 01:51 am, Chris Angelico wrote:

> On Sat, Oct 14, 2017 at 1:32 AM, Steve D'Aprano
>  wrote:
>> It seems to me that you're not talking about ROM at all, but ordinary RAM.
>> Then what do you mean by "read only"? A block of memory with a flag that
>> says "unprivileged processes are prohibited from writing here"?
>>
>> (That's also not a rhetorical question.)
> 
> When I first learned about Protected Mode (as defined by the Intel
> 80386 and used in OS/2), there was a real concept of read-only RAM.
> The program loader would fetch up the executable file (data on the
> disk) and construct its segments: code, data, and BSS/stack. The data,
> BSS, and stack all end up as a single segment (data is what comes
> straight off the disk, BSS is all zeroes initially, and stack is
> uninitialized initially, but ultimately they're all read/write), and
> code is in its own segment. When control is handed to the new process,
> its segment table grants it read/write access to the data/stack
> segment, but read-only access to its code segment.

> Within that 
> process, the code really truly is read-only, unless some magic is
> done. 

So... not actually read-only then?

You have the program loader writing to it, repeatedly, every time you load a
program. And even the unprivileged program itself can write to it, if it
knows the correct incantation to use. So its more like Read/Write Memory, or
as we normally call it, memory.

You know, an awful lot of confusion could have been avoided if people had
referred to write-protected memory as write-protected rather than read-only.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Sat, 14 Oct 2017 07:04 am, Peter J. Holzer wrote:

> On 2017-10-13 15:28, Steve D'Aprano  wrote:
>> On Sat, 14 Oct 2017 01:30 am, Chris Angelico wrote:
 It's just a technique, like greying out certain menu options - clicking
 them will do nothing, but you won't get an error message and you don't
 want to allow them anyway, risking more serious consequences.
>>> 
>>> Even there, you often CAN get a report about the failure; clicking on
>>> something that's disabled will cause a short beep, unless that's
>>> disabled. Maybe you personally don't like that beep, and you'd rather
>>> it be suppressed - but that's the end user's choice, NOT the
>>> programmer's. "Errors should never pass silently, unless explicitly
>>> silenced."
>>
>> Over 30 years since Apple first put out their user interface guidelines,
>> and people still get the basics wrong.
>>
>> "Errors should never pass silently..." is excellent advise for programming,
>> but not necessarily UIs. With a program, errors in the code represent bugs
>> that should be fixed, and in principle we can remove the bugs one by one
>> until there are none left, after which the program will be perfect. (Yeah,
>> try not to laugh too much.)
>>
>> But in a UI, that will never be the case. Errors are not bugs, and can't be
>> removed.
> 
> It is also not a bug if - for example - a file cannot be opened, or is
> malformed. But you have to tell the user what went wrong. Pretending
> that all went well won't make the user happy (or at least that happyness
> will be short-lived).

I don't disagree with that -- I never said that ALL errors should pass
silently. That would be silly. I said that UIs should be tolerant of
*unimportant* errors. Being unable to open a file is clearly not unimportant.

And besides, that's not really a UI error. Its either a programming error:

say, the code tries to call open("filename", "t")

or its an unavoidable environmental error (the file actually is corrupt, the
disk is failing, the user doesn't have read permission for the file). Either
case should be reported.


>> All you can do is hope the user doesn't do it again, which they
>> will. So UIs should follow a slightly different ideal:
>>
>> "Be tolerant of unimportant errors, and let them pass silently."
> [...]
>> Likewise, pressing the left arrow key when you are already at the start of
>> the text should just silently remain at the start, not chastise the user.
> [... other examples elided ...]
>> But in fact, clicking a disabled button or menu item is not an error.
> 
> If it is not an error, clearly the rule does not apply.

Indeed. That was my position: since clicking a disable menu item is not an
error, there's no need to treat it as an error. The action of disabling the
menu item or the button is an explicit way of saying:

temporary turn off the function of this item, and make
clicking it harmless

and once you have done so, there's no error condition to deal with because
clicking it does nothing.


> So it depends on 
> whether the action is an error or not (actually in the case of the
> disabled button I would tend to think it is an error: I can't think of a
> reason why anybody would intentionally click on a disabled button[1]).

Why do they need a reason? Maybe they just like to click on things. Since
clicking on disabled items is harmless, why elevate it to the state of an
error?

Maybe they're beginners to computers, and haven't yet learned the difference
between active controls that respond when you click them, and inactive ones
which do not respond. We all have to learn that, just as we learn which
entities respond to voice control, and which do not:

"Mummy, I'm thirsty, get me a glass of water please!"

"Whiskers, I'm thirsty, get me a glass of water please!"

The lack of response from the cat is enough to teach the user that asking your
cat is not going to be effective, and the lack of any feedback from a
disabled item likewise will quickly teach them that greyed out (disabled)
items are inactive and don't respond to clicks.

There's no need to treat it as an error and chastise the user, that just makes
your program hostile and less usable.


> Pressing the left arrow key when you are already at the start of the
> line is good example. The user might expect the cursor to jump the end
> of the previous line, 

I certainly do.

But that's why I specified the beginning of the text, not the beginning of the
line. There's no previous line to go back to.


> so if your program doesn't do that you probably 
> should give some feedback. Or the user might just have pressed the key a
> bit too long, then the cursor should just stop there ("vi has two modes:
> One beeps a lot and the other doesn't").

Also known as "annoy the user" and "sensible" modes :-)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Grant Edwards]

On 2017-10-14, Gregory Ewing  wrote:
>
>> I doubt that either process is in widespread usage any longer as
>> most manufacturers no incorporate a way to update the firmware of a
>> device
>
> Magnetic core technology died out long before that, due to
> inability to build machines that simulated armies of ladies
> with sewing needles!

I interviewed at a company that was still making core memory in 1989.

--
Grant



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

Re: Lies in education [was Re: The "loop and a half"]

[Steve D'Aprano]

On Fri, 13 Oct 2017 09:47 pm, Marko Rauhamaa wrote:

> "Peter J. Holzer" :
> 
>> On 2017-10-13 05:28, Gregory Ewing  wrote:
>>> Not only does "byte" not always mean "8 bits", but
>>> "char" isn't always short for "character"...
>>
>> True.
> 
> Well, it does, in my universe. That was cast in stone 10**-32 seconds
> after the Big Bang.

You've never had char-grilled peppers? *wink*



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Lies in education [was Re: The "loop and a half"]

[Chris Angelico]

On Sat, Oct 14, 2017 at 2:46 PM, Steve D'Aprano
 wrote:
> On Fri, 13 Oct 2017 09:47 pm, Marko Rauhamaa wrote:
>
>> "Peter J. Holzer" :
>>
>>> On 2017-10-13 05:28, Gregory Ewing  wrote:
 Not only does "byte" not always mean "8 bits", but
 "char" isn't always short for "character"...
>>>
>>> True.
>>
>> Well, it does, in my universe. That was cast in stone 10**-32 seconds
>> after the Big Bang.
>
> You've never had char-grilled peppers? *wink*

Yeah. They build character. *wink back*

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

Re: Return str to a callback raise a segfault if used in string formating

[dieter]

Thomas Jollans  writes:

> On 2017-10-13 11:07, Vincent Vande Vyvre wrote:
>> Le 13/10/17 à 09:23, Chris Angelico a écrit :
>>> On Fri, Oct 13, 2017 at 4:46 PM, Vincent Vande Vyvre
> ...
> If you have custom C code, it's likely that there is a memory management
> problem there. It's not unusual for incorrect memory management to cause
> problems in a completely different part of the code, where something
> tries to access freed memory or something.

It is very easy to get something wrong in custom C code.
Therefore, I typically use "cython" (a compiler translating extended
Python to C) to realize such code. It takes care of almost all
subleties.

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