Re: Multimeter USB output

[Joe]

Am 28.08.2016 um 17:22 schrieb Dennis Lee Bieber:

If you can read spaghetti coded C, you might want to study
https://sourceforge.net/projects/ut61/


Interesting, but... The last time I did something with c, it was with 
BDS-C under CM/M. Somebody remenbering this no-fp compiler from the dark 
age before PC und Linux?

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

Re: Multimeter USB output

[Joe]

Am 29.08.2016 um 10:54 schrieb Joe:

it was with BDS-C under CM/M.


under CP/M, of course.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Is duck-typing misnamed?

[Ben Finney]

Michael Torrie  writes:

> Umm no, she was actually a witch.  Which makes the scene even funnier.
> "Fair caught," she says at the end.

She says [0] “It's a fair cop”, which is using the term “cop” to mean
the arrest or sentence, asserting that it's justified.

Hence, the British term “copper”, meaning a police officer: the one who
does the cop (the capture or arrest) for a crime.

http://www.oxforddictionaries.com/definition/english/it%27s-a-fair-cop>
has quotations showing usage, as does
https://en.wiktionary.org/wiki/fair_cop>.


[0] http://www.sacred-texts.com/neu/mphg/mphg.htm>

-- 
 \   “Most people are other people. Their thoughts are someone |
  `\  else’s opinions, their lives a mimicry, their passions a |
_o__)   quotation.” —Oscar Wilde, _De Profundis_, 1897 |
Ben Finney

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

freqz -style plot of "window design" FIR?

[Matti Viljamaa]

I’m trying to design an arbitrary frequency response filter as described here:
http://www.dspguide.com/ch17/1.htm 

The technique is said to result in an impulse response in time domain and later 
in to a filter kernel.

I’ve been using scipy.signal.freqz to make magnitude response plots:

e.g.

fs = 44100

# Design a low-pass filter using remez.
cutoff = 2000.0
transition_width = 200
bands = np.array([0, cutoff - 0.5*transition_width,
  cutoff + 0.5*transition_width, fs/2.0]) / fs
desired = [1, 0]
lpf = remez(513, bands, desired)

# Plot the frequency response of the filter.
w, h = freqz(lpf)
plt.figure(1)
plt.plot(fs*w/(2*np.pi), 20*np.log10(abs(h)))
plt.xlim(0, fs/2)
plt.xlabel('Frequency (Hz)')
plt.ylabel('Gain (dB)')
plt.grid(True)

But my question is, if using the above arbitrary frequency response design 
technique, would I be able to use freqz?

freqz takes as a parameter “numerator of a linear filter” and remez is 
returning an array of coefficients, which I read to be the same thing.

But in the case of the arbitrary frequency response filter, what can I put into 
freqz? Is filter kernel perhaps the same as coefficients?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 29/08/2016 03:43, Steve D'Aprano wrote:



Your question seems to be, what happens if you follow that with an
assignment to a different type?

x = 5
some_code(x)
x = "hello world"


Will the type-checker consider that an error ("you're assigning a str to an
int") or will it infer that x is the Union[int, str]?

Surely that depends on the type-checker! I don't think there's any hard and
fast rule about that, but as far as I know, all statically typed languages
consider than an error.


In C, you can write this:

 int x;

 x = 5;
 x = "hello";

With certain compilers (eg. gcc) you only get a warning. (And since I 
don't show warnings to avoid inundation, that seems to compile fine for me!)


But you write:

 x = 5.1;

with no errors or warnings.


A dynamic type inference
system could easily cope with this:

x = 5
y = x**2
x = "five"
z = x.upper()

and correctly deduce that, at the time of y's assignment,
exponentiation of x was legal, and at the time of z's, uppercasing
was.


Could it? Do you have an example of a language or type-checker that can do
that? This isn't a rhetorical question.


Actually the above example is one of the easiest to perform 
type-inference on, where the variable has been assigned a known type on 
the previous line!


--
Bartc


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

PSA: Debian Stretch, apt-listchanges, and Python 3

[Chris Angelico]

If, like me, you build Python 3.6 from source and make it your default
'python3' binary, you may run into issues with the latest
apt-listchanges, which has switched to using Python 3. The symptom is
an ImportError trying to "import debconf", which is available in
dist-packages in the system Python, but (naturally) isn't part of
Python 3.6's install tree.

My solution:

sudo ln -s /usr/lib/python3/dist-packages/debconf.py
/usr/local/lib/python3.6/site-packages/

And then apt-listchanges happily sets itself up.

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

Re: What's the best way to minimize the need of run time checks?

[Chris Angelico]

On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:
> In C, you can write this:
>
>  int x;
>
>  x = 5;
>  x = "hello";
>
> With certain compilers (eg. gcc) you only get a warning. (And since I don't
> show warnings to avoid inundation, that seems to compile fine for me!)

That's because strings, in C, are really pointers-to-char, and for
hysterical raisins, pointers can be assigned to integers with just a
warning. (Good code should have an explicit cast here.)

You probably should have warnings enabled. There are a lot of faults
that newer languages flag as errors, but due to backward compat
restraints, C has to accept - but smart compilers will flag them as
warnings. Getting inundated with warnings would be a major code smell.

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

Re: What's the best way to minimize the need of run time checks?

[Steve D'Aprano]

On Mon, 29 Aug 2016 10:31 pm, Chris Angelico wrote:

> On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:
>> In C, you can write this:
>>
>>  int x;
>>
>>  x = 5;
>>  x = "hello";
>>
>> With certain compilers (eg. gcc) you only get a warning. (And since I
>> don't show warnings to avoid inundation, that seems to compile fine for
>> me!)
> 
> That's because strings, in C, are really pointers-to-char, and for
> hysterical raisins, pointers can be assigned to integers with just a
> warning. (Good code should have an explicit cast here.)

Let me see if I've got this straight... Bart's second assignment will
allocate a block of memory at least five bytes in size, stuff the ASCII
codes for 'h', 'e', 'l', 'l' and 'o' in that block (possibly with a null
byte at the end?) and then assign x to the address of that block.

Am I right?


That's better than my first thought, which was that it would write either

0x6865  ('he', if int is 16 bits)

or

0x68656c6c  ('hell', if int is 32 bits)


to x, and either discard the rest of the characters or just blindly write
them over the top of whatever variable (if any) happens to follow x in
memory.


> Getting inundated with warnings would be a major code smell.

"The low oil warning light in my car was always on, so I put some masking
tape over it so it wasn't bothering me any more."


It freaks me out something wicked when I run a major GUI application like
Firefox from the command line. Have you seen how many warnings and failed
assertions it generates? It is scary.




-- 
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: What's the best way to minimize the need of run time checks?

[Christian Gollwitzer]

Am 29.08.16 um 14:46 schrieb Steve D'Aprano:

On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:

In C, you can write this:

 int x;

 x = 5;
 x = "hello";



Let me see if I've got this straight... Bart's second assignment will
allocate a block of memory at least five bytes in size, stuff the ASCII
codes for 'h', 'e', 'l', 'l' and 'o' in that block (possibly with a null
byte at the end?) and then assign x to the address of that block.

Am I right?


Almost - the block of memory is statically allocated, i.e. there is a 
block of memory reserved for "constants" that are loaded on start-up of 
the program. x is assigned a pointer to that string. The difference is 
that you are not allowed to write to this memory area, for some 
compilers it causes a segfault if you try to write there.


YMMV - I consider this a gross abuse of "dark corners" in C.

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

Re: What's the best way to minimize the need of run time checks?

[Chris Angelico]

On Mon, Aug 29, 2016 at 10:46 PM, Steve D'Aprano
 wrote:
> On Mon, 29 Aug 2016 10:31 pm, Chris Angelico wrote:
>
>> On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:
>>> In C, you can write this:
>>>
>>>  int x;
>>>
>>>  x = 5;
>>>  x = "hello";
>>>
>>> With certain compilers (eg. gcc) you only get a warning. (And since I
>>> don't show warnings to avoid inundation, that seems to compile fine for
>>> me!)
>>
>> That's because strings, in C, are really pointers-to-char, and for
>> hysterical raisins, pointers can be assigned to integers with just a
>> warning. (Good code should have an explicit cast here.)
>
> Let me see if I've got this straight... Bart's second assignment will
> allocate a block of memory at least five bytes in size, stuff the ASCII
> codes for 'h', 'e', 'l', 'l' and 'o' in that block (possibly with a null
> byte at the end?) and then assign x to the address of that block.
>
> Am I right?

Mostly. Six for the \0 at the end, and the actual allocation happens
at compile time; this is a literal, so it means "have a thing
somewhere in memory that has h, e, l, l, o, \0, and I am its address".
So the actual run-time effect of this second assignment is simply to
set x to that address - which is effectively equivalent to "x = 5;"
with some other value. That's why it's permitted (with a warning). In
situations where you really WANT that, it's simple enough to demand
it:

x = (int)"hello";

but, as mentioned, backward compatibility means that this is permitted
without the explicit cast. Personally, I'd call it an error, and all
my C/C++ programs are designed to be compiled with -Wall, although I
don't necessarily demand utter silence from the compiler. Every
warning should be understood.

> That's better than my first thought, which was that it would write either
>
> 0x6865  ('he', if int is 16 bits)
>
> or
>
> 0x68656c6c  ('hell', if int is 32 bits)
>
>
> to x, and either discard the rest of the characters or just blindly write
> them over the top of whatever variable (if any) happens to follow x in
> memory.

Right, that's what would happen if you use single quotes (although
that's an extension). Interestingly, even though I'm on a 64-bit
system, gcc seems to work with 32-bit character constants at most;
it's happy to set x = 'helo', but x = 'hello' produces a "character
constant too long" warning and just uses 'ello'. (Actually, ANY
multi-character constant produces a warning, but that's because I have
it set to warn about all use of non-standard features. Not everyone
will.)

>> Getting inundated with warnings would be a major code smell.
>
> "The low oil warning light in my car was always on, so I put some masking
> tape over it so it wasn't bothering me any more."
>
>
> It freaks me out something wicked when I run a major GUI application like
> Firefox from the command line. Have you seen how many warnings and failed
> assertions it generates? It is scary.
>

Agreed, although not all of them are the fault of Firefox itself. I've
seen some GUI libraries that themselves produce warnings. Not good,
IMO.

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

Re: Is duck-typing misnamed?

[breamoreboy]

On Monday, August 29, 2016 at 12:08:26 PM UTC+1, Ben Finney wrote:
> Michael Torrie writes:
> 
> > Umm no, she was actually a witch.  Which makes the scene even funnier.
> > "Fair caught," she says at the end.
> 
> She says [0] “It's a fair cop”, which is using the term “cop” to mean
> the arrest or sentence, asserting that it's justified.
> 
> Hence, the British term “copper”, meaning a police officer: the one who
> does the cop (the capture or arrest) for a crime.
> 

Also used in the Dead Bishop sketch.

Klaus: It's a fair cop, but society's to blame.

Detective: Agreed. We'll be charging them too. 

Kindest regards.

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

Re: What's the best way to minimize the need of run time checks?

[Ben Bacarisse]

Steve D'Aprano  writes:

> On Mon, 29 Aug 2016 10:31 pm, Chris Angelico wrote:
>
>> On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:
>>> In C, you can write this:
>>>
>>>  int x;
>>>
>>>  x = 5;
>>>  x = "hello";
>>>
>>> With certain compilers (eg. gcc) you only get a warning. (And since I
>>> don't show warnings to avoid inundation, that seems to compile fine for
>>> me!)
>> 
>> That's because strings, in C, are really pointers-to-char,

They are really arrays of char, but array values convert to pointers to
the first element in so many situations that people end up thinking that
they are pointers.  The trouble is, once you start thinking they really
are pointers-to-char you have a harder time understanding things like
&"hello" and sizeof "hello".

>> and for
>> hysterical raisins, pointers can be assigned to integers with just a
>> warning. (Good code should have an explicit cast here.)

The code is wrong without a cast.  Many compilers, in their default
setting, are very generous about this situation, but the code is as
wrong a C code can be.  The assignment violates a language constraint
and the compiler would be permitted to refuse to generate any code at
all.

Given all that, it's something of an understatement to say that good
code should use a cast (which is always explicit).  (I'd go further and
say that good code should try to avoid doing this at all, and when it
absolutely must, it should use intptr_t rather than int.)

> Let me see if I've got this straight... Bart's second assignment will
> allocate a block of memory at least five bytes in size, stuff the ASCII
> codes for 'h', 'e', 'l', 'l' and 'o' in that block (possibly with a null
> byte at the end?) and then assign x to the address of that block.

Close, but the array of char is not generated by the assignment.  String
literals give rise to arrays with static storage duration (in effect
they exist before the start of the execution).  It will be 6 bytes in
size.

The assignment might do nothing at all because it violates a language
constraint about permitted types in an assignment.  But if it does do
something, a good bet will be to do the usual array to pointer
conversion and then try to convert that pointer to an int for
assignment.

> Am I right?
>
> That's better than my first thought, which was that it would write either
>
> 0x6865  ('he', if int is 16 bits)
>
> or
>
> 0x68656c6c  ('hell', if int is 32 bits)
>
> to x, and either discard the rest of the characters or just blindly write
> them over the top of whatever variable (if any) happens to follow x in
> memory.

Well, your first thought is not actually wrong.  In fact, a compiler
would be allowed to do that since the behaviour of a program that
violates a constraint is undefined by the language standard.  It would
not sell or get used much because people expect the traditional lax
treatment of pointers as integers, but it could do that.

>> Getting inundated with warnings would be a major code smell.
>
> "The low oil warning light in my car was always on, so I put some masking
> tape over it so it wasn't bothering me any more."

Yup.  Gcc lets you put masking tape on (-Wno-int-conversion) but, in
fairness, it also lets you treat all or selected warnings as hard errors
(-Werror=int-conversion).  Unfortunately there is no single option that
treats all serious situations as hard errors, presumably because no two
people agree on what should be considered serious for a particular
architecture.


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

Re: freqz -style plot of "window design" FIR?

[Matti Viljamaa]

Since I noticed this is better suited to the SciPy Users List, I moved it there:

https://mail.scipy.org/pipermail/scipy-user/2016-August/037023.html

> On 29 Aug 2016, at 14:34, Matti Viljamaa  wrote:
> 
> I’m trying to design an arbitrary frequency response filter as described here:
> http://www.dspguide.com/ch17/1.htm 
> 
> The technique is said to result in an impulse response in time domain and 
> later in to a filter kernel.
> 
> I’ve been using scipy.signal.freqz to make magnitude response plots:
> 
> e.g.
> 
> fs = 44100
> 
> # Design a low-pass filter using remez.
> cutoff = 2000.0
> transition_width = 200
> bands = np.array([0, cutoff - 0.5*transition_width,
>  cutoff + 0.5*transition_width, fs/2.0]) / fs
> desired = [1, 0]
> lpf = remez(513, bands, desired)
> 
> # Plot the frequency response of the filter.
> w, h = freqz(lpf)
> plt.figure(1)
> plt.plot(fs*w/(2*np.pi), 20*np.log10(abs(h)))
> plt.xlim(0, fs/2)
> plt.xlabel('Frequency (Hz)')
> plt.ylabel('Gain (dB)')
> plt.grid(True)
> 
> But my question is, if using the above arbitrary frequency response design 
> technique, would I be able to use freqz?
> 
> freqz takes as a parameter “numerator of a linear filter” and remez is 
> returning an array of coefficients, which I read to be the same thing.
> 
> But in the case of the arbitrary frequency response filter, what can I put 
> into freqz? Is filter kernel perhaps the same as coefficients?
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

Re: What's the best way to minimize the need of run time checks?

[Grant Edwards]

On 2016-08-29, Chris Angelico  wrote:
> On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:
>> In C, you can write this:
>>
>>  int x;
>>
>>  x = 5;
>>  x = "hello";
>>
>> With certain compilers (eg. gcc) you only get a warning. (And since
>> I don't show warnings to avoid inundation, that seems to compile
>> fine for me!)

If you're ignoring compiler warnings, you're asking for problems and
deserve whatever trouble you get.

> That's because strings, in C, are really pointers-to-char, and for
> hysterical raisins, pointers can be assigned to integers with just a
> warning. (Good code should have an explicit cast here.)
>
> You probably should have warnings enabled.

IMO, when doing doing development with GCC, -Wall -Werror is the
absolute minimum standard.

-- 
Grant Edwards   grant.b.edwardsYow! Will it improve my
  at   CASH FLOW?
  gmail.com

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

Re: What's the best way to minimize the need of run time checks?

[BartC]

On 29/08/2016 15:00, Grant Edwards wrote:

On 2016-08-29, Chris Angelico  wrote:

On Mon, Aug 29, 2016 at 10:13 PM, BartC  wrote:

In C, you can write this:

 int x;

 x = 5;
 x = "hello";

With certain compilers (eg. gcc) you only get a warning. (And since
I don't show warnings to avoid inundation, that seems to compile
fine for me!)


If you're ignoring compiler warnings, you're asking for problems and
deserve whatever trouble you get.


(It's my IDE that's not displaying the warnings because it can use any C 
compiler and some of them really will swamp the output with harmless 
warnings that often cannot be turned off (about unused labels for example).


The situation is a little unusual as normally the C being compiled has 
been machine-generated so the actual source has already been mostly 
verified. (And in that source language, assigning "hello" directly to x 
is an error as a cast is mandatory.)



That's because strings, in C, are really pointers-to-char, and for
hysterical raisins, pointers can be assigned to integers with just a
warning. (Good code should have an explicit cast here.)

You probably should have warnings enabled.


(Possibly they should be displayed when compiling 'straight' C. But then 
I wouldn't be able to 'assign a string to an integer' without any 
apparent problem!)


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

Magic UTF-8/Windows-1252 encodings

[Random832]

Directing this to python-list because it's really not on the topic of
the idea being discussed.

On Mon, Aug 29, 2016, at 05:37, Chris Angelico wrote:
> Suppose I come to python-ideas and say "Hey, the MUD community would
> really benefit from a magic decoder that would use UTF-8 where
> possible, ISO-8859-1 as fall-back, and Windows-1252 for characters not
> in 8859-1". Apart from responding that 8859-1 is a complete subset of
> 1252,

ISO-8859-1, with a dash in between "ISO" and "8859" is not a complete
subset of 1252. In fact, ISO-8859-1-with-a-dash incorporates ISO 6429
for 0x80-0x9F, and thereby has no bytes that do not map to characters.
The magic encoding that people often ask for or use is to use UTF-8
first, Windows-1252 as a fallback, and ISO 6429 as the final fallback
(and may or may not involve a "side trip" through Windows-1252 for UTF-8
encodings purportedly of code points between U+0080 and U+009F).

Incidentally, many Windows encodings, including 1252, as they are
actually used do use ISO 6429 for bytes that do not map to characters,
even when best fit mappings are not accepted. It is unclear why they
published tables that define these bytes as undefined, which have been
picked up by independent implementations of these encodings such as the
ones in Python. The only reason I can think of is to reserve the ability
to add new mappings later, as they did for 0x80 to U+20AC.

> there's not really a lot that you could discuss about that
> proposal, unless I were to show you some of my code. I can tell you
> about the number of MUDs that I play, the number of MUD clients that
> I've written, and some stats from my MUD server, and say "The MUD
> community needs this support", but it's of little value compared to
> actual code.
> 
> (For the record, a two-step decode of "UTF-8, fall back on 1252" is
> exactly what I do... in half a dozen lines of code. So this does NOT
> need to be implemented.)

And what level is the fallback done at? Per line? Per character? Per
read result? Does encountering an invalid-for-UTF-8 byte put it
permanently in Windows-1252 mode? Does it "retroactively" affect earlier
bytes? Can it be used as a stream encoding, or does it require you to
use bytes-based I/O and a separate .decode step?

I assume a MUD server isn't blocking on each client socket waiting for a
newline character, so how does such a decoding step mesh with whatever
such a server does to handle I/O asynchronously? Are there any
frameworks that you could be using that you can't if it's not an
encoding?

What happens if it's being used as an incremental decoder, encounters a
valid UTF-8 lead byte on a buffer boundary, and then must "reject" (i.e.
decode as the fallback encoding) it afterwards because an invalid trail
byte follows it in the next buffer? What happens if a buffer consists
only of a valid partial UTF-8 character?

I can probably implement the fallback as an error handler in half a
dozen lines, but it's not obvious and I suspect it's not what a lot of
people do. It would probably take a bit more than half a dozen lines to
implement it as an encoding.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Magic UTF-8/Windows-1252 encodings

[Chris Angelico]

On Tue, Aug 30, 2016 at 12:38 AM, Random832  wrote:
> Directing this to python-list because it's really not on the topic of
> the idea being discussed.
>
> On Mon, Aug 29, 2016, at 05:37, Chris Angelico wrote:
>> Suppose I come to python-ideas and say "Hey, the MUD community would
>> really benefit from a magic decoder that would use UTF-8 where
>> possible, ISO-8859-1 as fall-back, and Windows-1252 for characters not
>> in 8859-1". Apart from responding that 8859-1 is a complete subset of
>> 1252,
>
> ISO-8859-1, with a dash in between "ISO" and "8859" is not a complete
> subset of 1252. In fact, ISO-8859-1-with-a-dash incorporates ISO 6429
> for 0x80-0x9F, and thereby has no bytes that do not map to characters.
> Incidentally, many Windows encodings, including 1252, as they are
> actually used do use ISO 6429 for bytes that do not map to characters,
> even when best fit mappings are not accepted. It is unclear why they
> published tables that define these bytes as undefined, which have been
> picked up by independent implementations of these encodings such as the
> ones in Python. The only reason I can think of is to reserve the ability
> to add new mappings later, as they did for 0x80 to U+20AC.

Huh, okay. Anyway, point is that it's a magical decoder that tries
UTF-8, and if that fails, uses an eight-bit encoding.

>> there's not really a lot that you could discuss about that
>> proposal, unless I were to show you some of my code. I can tell you
>> about the number of MUDs that I play, the number of MUD clients that
>> I've written, and some stats from my MUD server, and say "The MUD
>> community needs this support", but it's of little value compared to
>> actual code.
>>
>> (For the record, a two-step decode of "UTF-8, fall back on 1252" is
>> exactly what I do... in half a dozen lines of code. So this does NOT
>> need to be implemented.)
>
> And what level is the fallback done at? Per line? Per character? Per
> read result? Does encountering an invalid-for-UTF-8 byte put it
> permanently in Windows-1252 mode? Does it "retroactively" affect earlier
> bytes? Can it be used as a stream encoding, or does it require you to
> use bytes-based I/O and a separate .decode step?

Currently? UTF-8 is attempted on an entire read result, and if it
fails, the data is cracked into individual lines and retried, using
the fallback as per the above. So in effect, it's per line. I
basically assume that a naive byte-oriented server is usually going to
be spitting out data from one client at a time, and each client is
either emitting UTF-8 or its native encoding. (Since I have no way of
knowing what native encoding a given client was using, I just pick
Western Europe as the most likely codepage and run with it. The
algorithm would work just the same if I picked, say, Windows-1250 as
the eight-bit encoding.)

> I assume a MUD server isn't blocking on each client socket waiting for a
> newline character, so how does such a decoding step mesh with whatever
> such a server does to handle I/O asynchronously? Are there any
> frameworks that you could be using that you can't if it's not an
> encoding?

This magic started out in my MUD client, where it's connecting to a
naive server that echoes whatever it's given. The same logic is now in
my MUD server, too. It's pretty simple in both cases; the client is
built around asynchronous I/O, the server is threaded, but both of
them have a single point in the code where new bytes come in. There's
one function that converts bytes to text, and it operates on the above
algorithm.

> What happens if it's being used as an incremental decoder, encounters a
> valid UTF-8 lead byte on a buffer boundary, and then must "reject" (i.e.
> decode as the fallback encoding) it afterwards because an invalid trail
> byte follows it in the next buffer? What happens if a buffer consists
> only of a valid partial UTF-8 character?

Hmm, I don't remember if there's any actual handling of this. If
there's a problem, my solution is simple: split on 0x0A first, and
then decode, which means I'm decoding one line at a time. Both server
and client already are fundamentally line-based anyway, and depending
on byte value 0x0A always and only representing U+000A is valid in all
of the encodings that I'm willing to accept.

> I can probably implement the fallback as an error handler in half a
> dozen lines, but it's not obvious and I suspect it's not what a lot of
> people do. It would probably take a bit more than half a dozen lines to
> implement it as an encoding.

Please don't. :) This is something that belongs in the application;
it's somewhat hacky, and I don't see any benefit to it going into the
language. For one thing, I could well imagine making the fallback
encoding configurable (it isn't currently, but it could easily be),
and that doesn't really fit into the Python notion of error handler.
For another, this is a fairly rare concept - I don't see dozens of
programs out there using the exact same strange lo

Re: Magic UTF-8/Windows-1252 encodings

[Random832]

On Mon, Aug 29, 2016, at 11:14, Chris Angelico wrote:
> Please don't. :) This is something that belongs in the application;
> it's somewhat hacky, and I don't see any benefit to it going into the
> language. For one thing, I could well imagine making the fallback
> encoding configurable (it isn't currently, but it could easily be),
> and that doesn't really fit into the Python notion of error handler.

Well, yeah, if anything implementing it as an error handler is a hack, I
just meant it's just the least hacky way I can think that fits in the
size "half a dozen lines".

> For another, this is a fairly rare concept - I don't see dozens of
> programs out there using the exact same strange logic, and even if
> there were, there'd be small differences

That is actually an argument in favor of putting it in the stdlib,
assuming few of those small differences are truly considered and
intentional. The main thrust of my post was that this is one of the
things that's harder than it sounds to get right due to edge cases, just
like the clip/clamp function being discussed last month.

> (eg whether or not the
> fallback is applied line-by-line). This was intended as an example of
> something that does NOT belong in the core language, and while I
> appreciate the offer of help, it's not something I'd support polluting
> the language with :)
> 
> (Plus, my server's not written in Python. Nor is the client that this
> started in, although I have considered writing a version of it in
> Python, which would in theory benefit from this.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Magic UTF-8/Windows-1252 encodings

[Chris Angelico]

On Tue, Aug 30, 2016 at 1:28 AM, Random832  wrote:
> On Mon, Aug 29, 2016, at 11:14, Chris Angelico wrote:
>> Please don't. :) This is something that belongs in the application;
>> it's somewhat hacky, and I don't see any benefit to it going into the
>> language. For one thing, I could well imagine making the fallback
>> encoding configurable (it isn't currently, but it could easily be),
>> and that doesn't really fit into the Python notion of error handler.
>
> Well, yeah, if anything implementing it as an error handler is a hack, I
> just meant it's just the least hacky way I can think that fits in the
> size "half a dozen lines".
>
>> For another, this is a fairly rare concept - I don't see dozens of
>> programs out there using the exact same strange logic, and even if
>> there were, there'd be small differences
>
> That is actually an argument in favor of putting it in the stdlib,
> assuming few of those small differences are truly considered and
> intentional. The main thrust of my post was that this is one of the
> things that's harder than it sounds to get right due to edge cases, just
> like the clip/clamp function being discussed last month.

Fair enough. If this were something that a lot of programs wanted,
then yeah, there'd be good value in stdlibbing it. Character encodings
ARE hard to get right, and this kind of thing does warrant some help.
But I think it's best not done in core - at least, not until we see a
lot more people doing the same :)

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

How to get Read the Docs to generate py-modindex.html?

[Charles Ross]

Since I appear to be experiencing one of the few times that Stack Overflow 
hasn’t provided any quick answers to a problem 
(http://stackoverflow.com/questions/39197037/how-to-get-read-the-docs-to-generate-py-modindex-html
 
),
 I’ll try posting my question here and see if anyone has a suggestion.

I'm trying to get Read the Docs to generate the `py-modindex.html` file. 
Research into a related question lead me to the following setup:

- `setup.py` in the project directory has the following contents, which were 
the minimum needed to get `pytest` to work and haven't been changed since I got 
that part of my project working:

import setuptools

setuptools.setup(
name='polygons',
packages=setuptools.find_packages(),
)

- `docs/requirements.txt` contains a single line:

sphinx-autodoc-annotation

- The Read the Docs repository URL points to my repository 
(https://github.com/chivalry/polygons).
- The RtD setting for "Install your project inside a virtualenv using setup.py 
install" is checked.
- The RtD setting for "Requirements file" points to `docs/requirements.txt`.

The "Module Index" link gets included in `index.html` 
(http://polygons.readthedocs.io/en/latest/), but the `py-modindex.html` file is 
missing.

My understanding is that with the virtualenv setting above, RtD will use the 
`setup.py` file to install the project so that Sphinx can read the 
documentation found in the Python docstrings. I'm using function annotations 
and would like `sphyinx-autodoc-annotation` to make use of those when creating 
the built docs files. All of this works splendidly on my local machine when I 
run `make html` while in the `docs` folder. Now I'm trying to get it to work on 
Read the Docs.

Thanks,
Chuck

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

Re: Multimeter USB output

[Rob Gaddi]

Joe wrote:

> The UT61B has two interfaces, a RS232C interface and this usb interface. 
> The RS232 interface works well with PySerial. It continously transmits 2 
> .. 3 Pakets per second with 14 Bytes each. This happens unsolicited 
> without any command as long as the RS232C/USB button on the DMM is active.
>

>From someone who does a LOT of code to talk to DMMs, scopes, counters,
etc?  Word of advice.  You're done.  Declare victory and move on.

You've got it working on one interface.  The other is even less well
documented and requires doing deep-down stuff against libusb because
there's no actual kernel driver, and you've got a Chinese manufacturer
of a low-end device being of little to no help so now you're trying to
reverse engineer the protocol from bad code without even the help of a
packet sniffer.  This is the sort of rabbit hole that weeks manage to
fall into with nothing to show for them.

If this is an exercise in learning to work with libusb then have at. 
But if what you actually need from this is to talk to the meter?  You're
talking to it already.  Take the win and walk.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
-- 
https://mail.python.org/mailman/listinfo/python-list

Helloworld with Python C extension

[Ganesh Pal]

 Hello Team ,

I need you input on the below  hello world program.  I a m trying to add a
python binding which will return the character for the given index .  I am
on Python 2.7   and linux

Example :
>> string ='helloworld'
>>dda_hello(5)
>> 'w'


 /*
+ * Hello world example for python bindings
+ */
+
+static char* string = "helloworld";
+char dda_hello(int i)
+ {
+  return string[i];
+ }
+
+static PyObject *
+py_dda_hello(PyObject *self, PyObject *args )
+{
+   int index;
+   char char1;
+   if (!PyArg_ParseTuple(args, "i", &index))
+   return NULL;
+   char1 = dda_hello(index);
+   return Py_BuildValue("s",char1);
+}
+
+/*

@@ -1674,6 +1705,10 @@ PyMethodDef xyz_methods[] = {
+{"dda_hello", py_dda_hello, METH_VARARGS,
+"Returns the character entered for a given index"},


>>>  import as.ds.dss as daa
>>> print dda.dda_hello(1)
zsh: segmentation fault (core dumped)  python

Apologies for posting the diff  , I didn't find a better way

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Helloworld with Python C extension

[Chris Angelico]

On Tue, Aug 30, 2016 at 3:30 AM, Ganesh Pal  wrote:
> +char dda_hello(int i)
> + {
> +  return string[i];
> + }
> +
> +   return Py_BuildValue("s",char1);

Py_BuildValue with an "s" expects a C string - that is, a pointer to
char, not just a single character. You'd need to do something like
this:

char buf[2] = {char1, 0};
return Py_BuildValue("s", buf);

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

Re: Helloworld with Python C extension

[MRAB]

On 2016-08-29 18:30, Ganesh Pal wrote:

 Hello Team ,

I need you input on the below  hello world program.  I a m trying to add a
python binding which will return the character for the given index .  I am
on Python 2.7   and linux

Example :

string ='helloworld'
dda_hello(5)
'w'



 /*
+ * Hello world example for python bindings
+ */
+
+static char* string = "helloworld";
+char dda_hello(int i)
+ {
+  return string[i];
+ }
+
+static PyObject *
+py_dda_hello(PyObject *self, PyObject *args )
+{
+   int index;
+   char char1;
+   if (!PyArg_ParseTuple(args, "i", &index))
+   return NULL;
+   char1 = dda_hello(index);


This bit is wrong:


+   return Py_BuildValue("s",char1);


The format "s" is for a null-terminated C string (char *), but you're 
giving it a C int.


The format you should be using is "c" (C int representing a character).


+}
+
+/*

@@ -1674,6 +1705,10 @@ PyMethodDef xyz_methods[] = {
+{"dda_hello", py_dda_hello, METH_VARARGS,
+"Returns the character entered for a given index"},



 import as.ds.dss as daa
print dda.dda_hello(1)

zsh: segmentation fault (core dumped)  python

Apologies for posting the diff  , I didn't find a better way

It would be a good idea to check the index and raise an exception if 
it's out the bounds.


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

importing down in code rather than at top of file.

[Tobiah]

Is it  worth while to defer the import of a large module that seldom
gets used in the script?


import sys
import os

if hardly_ever_happens():

import large_module
large_module.do_task()



I imagine it takes a certain amount of processing
power and memory to import a module, so it seems
like I'd save those resources with the above pattern.

The down side would be that it's nice to see all of the
imports at the top which would follow convention.  Should
I care?


Tobiah



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

Re: importing down in code rather than at top of file.

[Chris Angelico]

On Tue, Aug 30, 2016 at 3:57 AM, Tobiah  wrote:
> Is it  worth while to defer the import of a large module that seldom
> gets used in the script?
>
>
> import sys
> import os
>
> if hardly_ever_happens():
>
> import large_module
> large_module.do_task()
>
>
>
> I imagine it takes a certain amount of processing
> power and memory to import a module, so it seems
> like I'd save those resources with the above pattern.
>
> The down side would be that it's nice to see all of the
> imports at the top which would follow convention.  Should
> I care?

Don't imagine; test. Time your program with and without a top-of-file
import. If the module really is large (and by "large" I mean on the
scale of numpy - huge stuff), then yes, it's worth it. If you can't
measure the difference, though, don't bother - just import it and have
done with it.

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

Re: importing down in code rather than at top of file.

[alister]

On Mon, 29 Aug 2016 10:57:22 -0700, Tobiah wrote:

> Is it  worth while to defer the import of a large module that seldom
> gets used in the script?
> 
> 
>   import sys import os
> 
>   if hardly_ever_happens():
>   
>   import large_module large_module.do_task()
> 
> 
> 
> I imagine it takes a certain amount of processing power and memory to
> import a module, so it seems like I'd save those resources with the
> above pattern.
> 
> The down side would be that it's nice to see all of the imports at the
> top which would follow convention.  Should I care?
> 
> 
> Tobiah

That depends
does it actually make a significant delay to the loading of your 
application (have you timed it yet)

if the module does take a noticeable time to load do you want that 
additional delay in your rarely access conditions?

IMO start-up times for an application have to be significantly long 
before they become an issue unless they are a shout quick utility

example Libra office an take a few seconds to start but then will be 
running for a long time - the start-up time is not really significant.
a utility to perform a bulk rename you would not want to take 30 seconds 
to start if it would then complete in less than 1

remember the golden riules for optimisation

1) don't
2) (for advanced programmers only) Don't yet.




-- 
In a world without fences who needs Gates?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Helloworld with Python C extension

[Stefan Behnel]

Ganesh Pal schrieb am 29.08.2016 um 19:30:
> I need you input on the below  hello world program.  I a m trying to add a
> python binding which will return the character for the given index .  I am
> on Python 2.7   and linux
> 
> Example :
> >>> string ='helloworld'
> >>> dda_hello(5)
> >>> 'w'
> 
>  /*
> + * Hello world example for python bindings
> + */
> +
> +static char* string = "helloworld";
> +char dda_hello(int i)
> + {
> +  return string[i];
> + }
> +
> +static PyObject *
> +py_dda_hello(PyObject *self, PyObject *args )
> +{
> +   int index;
> +   char char1;
> +   if (!PyArg_ParseTuple(args, "i", &index))
> +   return NULL;
> +   char1 = dda_hello(index);
> +   return Py_BuildValue("s",char1);
> +}
> +
> +/*
> 
> @@ -1674,6 +1705,10 @@ PyMethodDef xyz_methods[] = {
> +{"dda_hello", py_dda_hello, METH_VARARGS,
> +"Returns the character entered for a given index"},

Here's a Cython implementation (http://cython.org) of your example:

cdef str string = "helloworld"

def dda_hello(int i):
return string[i]

It uses a lot less code than the C-implemented version, but is compatible
with Python 2 and Python 3 and avoids pitfalls like the crash you are
seeing, as well as raising a proper IndexError for invalid index arguments
(and it supports negative indexing). I also wouldn't be surprised if it's
visibly faster than your C implementation.

Unless your intention is to explicitly learn how to use the CPython C-API,
you should give Cython a try instead.

Stefan


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

Re: importing down in code rather than at top of file.

[Nobody]

On Tue, 30 Aug 2016 04:15:05 +1000, Chris Angelico wrote:

> Don't imagine; test.

Testing alone isn't really good enough. There may be perfectly valid
reasons to avoid the import which won't show up in anything less than the
most thorough testing imaginable.

Personally I wouldn't defer an import just because it might be slow,
particularly if the criterion affecting whether the import actually occurs
is "probabilistic".

[If it might be slow because the module is doing stuff it really
shouldn't, like executing external commands during import, I'd probably
just avoid the package altogether.]

If the import /might/ happen as a result of normal usage, I'd want any
failure to occur when the parent module is imported, not at some rather
arbitrary later point.

If I defer imports, it's because they're only used for features which are
in some sense optional. And the documentation will state the conditions
under which the import is performed (if it's for a specific method, it
will be in the method's docstring).

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

Re: importing down in code rather than at top of file.

[Terry Reedy]

On 8/29/2016 1:57 PM, Tobiah wrote:

Is it  worth while to defer the import of a large module that seldom
gets used in the script?


import sys
import os

if hardly_ever_happens():

import large_module
large_module.do_task()



I imagine it takes a certain amount of processing
power and memory to import a module, so it seems
like I'd save those resources with the above pattern.

The down side would be that it's nice to see all of the
imports at the top which would follow convention.  Should
I care?


If you delay the import, you can put it a function, such as 'almost 
never', and then document the delayed import with comments either mixin 
in with or below the real ones, such as


# import large_module  # in almost_never

--
Terry Jan Reedy

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

Re: PSA: Debian Stretch, apt-listchanges, and Python 3

[Matt Wheeler]

I think the real PSA is "don't mess with the system python(3) version".

On Mon, 29 Aug 2016 at 13:18 Chris Angelico  wrote:

> If, like me, you build Python 3.6 from source and make it your default
> 'python3' binary, you may run into issues with the latest
> apt-listchanges, which has switched to using Python 3. The symptom is
>

This is a good example of the reason why it's a bad idea to mess with the
system python on any OS (and every so often people get berated on this list
for doing just that, although usually on OSX, where it's actually less of
an issue :).


> an ImportError trying to "import debconf", which is available in
> dist-packages in the system Python, but (naturally) isn't part of
> Python 3.6's install tree.
>
> My solution:
>
> sudo ln -s /usr/lib/python3/dist-packages/debconf.py
> /usr/local/lib/python3.6/site-packages/
>
> And then apt-listchanges happily sets itself up.
>

So you've managed to fix this issue, but what if there are others? I think
packages on Debian have a reasonable right to expect that the version of
python3 in the release is the version they are going to run on if they look
like `#!/usr/bin/env python3 ...`

Why not simply alias python3 to python3.6 for your user, or make use of
virtualenvs?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PSA: Debian Stretch, apt-listchanges, and Python 3

[Chris Angelico]

On Tue, Aug 30, 2016 at 11:58 AM, Matt Wheeler  wrote:
> I think the real PSA is "don't mess with the system python(3) version".
>
> So you've managed to fix this issue, but what if there are others? I think
> packages on Debian have a reasonable right to expect that the version of
> python3 in the release is the version they are going to run on if they look
> like `#!/usr/bin/env python3 ...`
>
> Why not simply alias python3 to python3.6 for your user, or make use of
> virtualenvs?

Up until very recently, the system Python has only been the Python 2.
(For a while, it wasn't even 2.7, but I could easily use altinstall
for that.) I have deliberately wanted to use 3.6 for ALL testing, not
just by messing with venvs or shell aliases, in order to enforce
dogfooding on everything (and for consistency); older Pythons are
available as python3.4 and python3.5, but the live python3 has always
been the one built from tip. And even as Debian starts to embrace Py3
internally, this hasn't been a problem.

If your goal is stability, sure. Don't mess with what 'env python3'
runs. But if you want to thoroughly test stuff? That's different.

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

Re: Multimeter USB output

[Larry Hudson via Python-list]

On 08/29/2016 01:54 AM, Joe wrote:
[snip...]

Interesting, but... The last time I did something with c, it was with BDS-C 
under CM/M. Somebody
remenbering this no-fp compiler from the dark age before PC und Linux?


I remember it well.  It's what I used to initially learn C.  I'm a completely self-taught, hobby 
programmer.  Been around since the MITS Altair.  How many remember that beast??


(And yes -- as you already corrected yourself -- that's CP/M not CM/M.)

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

Re: Multimeter USB output

[Paul Rubin]

Larry Hudson  writes:
>> with BDS-C under CP/M. Somebody remenbering this no-fp compiler from
>> the dark age before PC und Linux?
> I remember it well.  It's what I used to initially learn C.

Source code is online here:

http://www.bdsoft.com/resources/bdsc.html

I've looked at it a little.  I don't know if I ever might have had it in
me to write big chunks of asm code like that.  Wow!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PSA: Debian Stretch, apt-listchanges, and Python 3

[Matt Ruffalo]

On 2016-08-29 23:56, Chris Angelico wrote:
> Up until very recently, the system Python has only been the Python 2.
> (For a while, it wasn't even 2.7, but I could easily use altinstall
> for that.) I have deliberately wanted to use 3.6 for ALL testing, not
> just by messing with venvs or shell aliases, in order to enforce
> dogfooding on everything (and for consistency); older Pythons are
> available as python3.4 and python3.5, but the live python3 has always
> been the one built from tip. And even as Debian starts to embrace Py3
> internally, this hasn't been a problem.
>
> If your goal is stability, sure. Don't mess with what 'env python3'
> runs. But if you want to thoroughly test stuff? That's different.
>
> ChrisA

This seems like a reasonably large problem on Debian's part. I was under
the impression that system-critical Python scripts used absolute paths
in their hashbang lines, to avoid exactly this situation. If something
really depends on the system Python version (whichever 2.x or 3.x that
might be), it should explicitly use that Python installation. User
scripts, of course, should use "/usr/bin/env python3" to be usable in a
virtualenv or under whatever Python installation the user chooses.

I believe the Gentoo package manager has logic to adjust the hashbang
lines of Python scripts if a package requests it, and I'm not as
familiar with Debian packaging but I'd be surprised if the Debian tools
were missing this functionality.

MMR...

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

Re: Helloworld with Python C extension

[Ganesh Pal]

>
>
>
> Py_BuildValue with an "s" expects a C string - that is, a pointer to
> char, not just a single character. You'd need to do something like
> this:
>
> char buf[2] = {char1, 0};
> return Py_BuildValue("s", buf);
>
> ChrisA


Thanks  Chris for the clue's   it worked,  I  was just wondering  how
could the
C extension   be debugged ?

 We have pdb at python side and gdb for C  , can we run gdb on python side
?  if there is a crash like the one we saw in the above diff we are
clueless of what's happening? any idea or recommendation on how we handle
such cases

Regards,
Ganesh
-- 
https://mail.python.org/mailman/listinfo/python-list