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

[issue11734] Add half-float (16-bit) support to struct module

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11734] Add half-float (16-bit) support to struct module

[Raymond Hettinger]

Raymond Hettinger added the comment:

In the docs for note 7, consider expanding the text to describe what a 
half-float is (1-bit sign, 10 bit significand, 5 bit exponent) and its 
allowable range.  This wasn't necessary for codes "f" and "d" since they have 
well-known C equivalents, but in this case some elaboration is needed.  Also 
consider  including a link to the wikipedia article and perhaps to IEEE 
754-2008.

Otherwise, he patch looks complete and passes the test suite.  I think it is 
ready to apply.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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: 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

[issue27879] add os.syncfs()

[Марк Коренберг]

Марк Коренберг added the comment:

1. It is appropriate to call `sync()` when one calls `os.syncfs()` if 
`syncfs()` syscall is not supported in kernel.
2. https://technet.microsoft.com/sv-se/sysinternals/bb897438(en-us).aspx
3. https://github.com/EricGrange/FlushFileCache ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21541] Provide configure option --with-ssl for compilation with custom openssl

[Gregory P. Smith]

Gregory P. Smith added the comment:

We use Modules/Setup.local to build the _ssl and _hashlib modules against our 
an SSL library of our choosing at work using a Setup entry like this:

_ssl _ssl.c $(PY_CORE_CFLAGS) -DUSE_SSL -I%{SSL_ROOT}/include \
-Wl,--version-script,_ssl.lds \
-Wl,-Bsymbolic \
%{SSL_ROOT}/libssl.a %{SSL_ROOT}/libcrypto.a

%{SSL_ROOT} is replaced prior to building using sed to drop in the path to our 
desired libssl build.

_ssl.lds is a linker script to hide all but the module init function as we are 
linking statically.

MODULE__ssl {
  global: PyInit__ssl;
  local: *;
};


(all that said, I still see how a configure flag would be nicer for many people 
even though the existing patch does not look like it would work for our own 
static linking needs - one reason we do that being to avoid dynamic versioning 
issues)

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21541] Provide configure option --with-ssl for compilation with custom openssl

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24254] Make class definition namespace ordered by default

[Nick Coghlan]

Nick Coghlan added the comment:

Because we're not making ordered-by-default dicts a language specification 
level requirement, so portable code can't rely on them.

However, the PEP at https://www.python.org/dev/peps/pep-0520/ is deliberately 
worded so that there's no requirement for the class body execution namespace to 
specifically be collections.OrderedDict - it just needs to be order preserving 
so that __definition_order__ can be populated.

If someone reviews and merges the compact ordered dict patch, then this patch 
can likely be made a lot simpler.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27891] Consistently group and sort imports within idlelib modules.

[Terry J. Reedy]

Terry J. Reedy added the comment:

On 2002 Sept 14, the following was merged into editor.py (then EditorWindow.py) 
as part of the smart indenting code added to the bottom.

import tokenize
_tokenize
del tokenize

This now would usually be written "import tokenize as _tokenize".  Stdlib 
modules without explicit __all__ often do this to omit stdlib modules from 
their public interface.  Idlelib does not do this.  Add to README import 
standards.  I put replaced the above with 'import tokenize' as the top where is 
belongs and changed all '_tokenize' to 'tokenize'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27892] Idlelib: document or move delayed imports

[Terry J. Reedy]

Terry J. Reedy added the comment:

Another good reason for delaying an import is when the import is only needed 
for testing.

In module_x
...
def callable_x(parent)  # htest #
from tkinter import Toplevel
box = Toplevel(parent)
...
if __name__ == '__main__':
from unittest import main
main('idlelib.idle_test.test_module_x', verbosity=2)

from idlelib.idle_test.htest import run
run(callable_x)

This should be part of 'Import Standards' in idlelib.README.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27891] Consistently group and sort imports within idlelib modules.

[Terry J. Reedy]

Terry J. Reedy added the comment:

This issue includes adding the idlelib import coding standard to idlelib.README.

The delayed-import issue is #27893.

A second followup will be to stop importing tkinter modules 'as' their Py 2 
names.  Change "from tkinter import font as TkFont" to "from tkinter import 
font" and globally replace 'TkFont' with 'tkfont'.  Do the same for messagebox 
and any other submodules as needed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27889] ctypes interfers with signal handling

[Andre Merzky]

Andre Merzky added the comment:

Thanks for checking!  I use:

$ uname -a
Linux thinkie 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux

$ python -V
Python 2.7.5+


Note that the problem does not occur on every run -- but in more than 50% of 
the cases, for me.  I am on a somewhat old machine right now (M620), not sure 
if that matters, and will try to reproduce on some other boxes tomorrow.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27892] Idlelib: document or move delayed imports

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
dependencies: +Consistently group and sort imports within idlelib modules.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27892] Idlelib: document or move delayed imports

[Terry J. Reedy]

New submission from Terry J. Reedy:

This issue depends and follows-up on #27891, consistently grouping and sorting 
imports in idlelib files.

PEP 8 (also) says 'all imports are put at the top of the file', though the 
'consistency hobgloblin' rule allows for exceptions.  Possible reasons include 
making circular imports work, delaying side-effects, and significantly reducing 
initial import time of the containing module.   All are rare.

Idlelib currently has numerous exceptions, only a few of which have a 
documented reason.  The others might have a good reason, but may be holdovers 
from when 'import at top' was absent or not observed.  I propose to at least 
document the exceptions by putting comments at the top, in their sort location 
among other idlelib imports.  Examples: 

# from idlelib import module  # in EditorWindow
# from idlelib.other import SomeClass  # in EditorWindow

Doing this will make it possible to see at a glance all the idlelib imports in 
a module.

I will remove at least one redundant delayed import and move some when I am 
sure there is no reason not to.  I may ask original authors as to their reason 
for placing imports where they did.

Moving 'import X' from a function is easy and safe.  Moving an import from a 
class requires deleting 'self.' from all references, so is not safe without 
extra care.  At least for EditorWindow, I may leave this to when editing the 
class anyway.

--
assignee: terry.reedy
components: IDLE
messages: 273893
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idlelib: document or move delayed imports
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27891] Consistently group and sort imports within idlelib modules.

[Terry J. Reedy]

New submission from Terry J. Reedy:

PEP 8 suggests separately grouping stdlib, dependency, and local package 
imports.  Within idlelib, idlelib imports are treated as local package imports. 
 Tkinter is sometimes treated as a dependency, which makes its imports easy to 
notice, and I want to do this consistently.  It is conventional to sort imports 
within each group.  This is sometimes true now, sometimes not (even before the 
3.6 renaming).

The possible danger of rearranging imports is that a line gets deleted and not 
pasted.  Rietveld's side-by-side diff should make this easy to detect.

This issue is about re-arranging the imports currently at the top of a file, 
and any module level imports that I notice elsewhere.  Dealing with delayed 
imports within functions and classed will be another issue, which will depend 
on this one.

--
assignee: terry.reedy
components: IDLE
messages: 273892
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Consistently group and sort imports within idlelib modules.
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27350] Compact and ordered dict

[INADA Naoki]

Changes by INADA Naoki :


Added file: https://bugs.python.org/file44259/compact-dict.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27889] ctypes interfers with signal handling

[Eryk Sun]

Eryk Sun added the comment:

I can't reproduce this issue in 2.7.11 on Linux. I also don't see how it could 
be related to ctypes. It doesn't meddle with signal handlers, and neither does 
Linux libuuid -- not as far I as I can tell with breakpoints set on signal() 
and sigaction(). Please provide the Python version and platform that you're 
using.

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27890] platform.release() incorrect in Python 3.5.2 on Windows 2008ServerR2

[James Domingo]

New submission from James Domingo:

The platform.release() function in Python 3.5.1 returns the correct value on 
Windows 2008 Server R2:

  C:\Users\jdoe\Documents\Python>python-3.5.1-embed-amd64\python.exe
  Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit 
(AM
  D64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.release()
  '2008ServerR2'

However, the function in the latest release, Python 3.5.2, misidentifies the 
system as Windows 7:

  C:\Users\jdoe\Documents\Python>python-3.5.2-embed-amd64\python.exe
  Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit 
(AM
  D64)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import platform
  >>> platform.release()
  '7'

--
components: Library (Lib)
messages: 273890
nosy: James Domingo
priority: normal
severity: normal
status: open
title: platform.release() incorrect in Python 3.5.2 on Windows 2008ServerR2
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27889] ctypes interfers with signal handling

[Andre Merzky]

New submission from Andre Merzky:

Summary:  A thread uses signals to the MainThread to signal an abnormal 
condition.  The main thread is expected to get that signal, invoke the signal 
handler, and raise an exception.  In combination with 'ctypes' calls, that does 
not happen.


Consider the following code:


#!/usr/bin/env python

import multiprocessing as mp
import threading   as mt
import signal
import time
import os

# from uuid.py line 400
import ctypes, ctypes.util
lib = ctypes.CDLL(ctypes.util.find_library('uuid'))

def sigusr2_handler(signum, frame):
raise RuntimeError('caught sigusr2')
signal.signal(signal.SIGUSR2, sigusr2_handler)

def sub(pid):
time.sleep(1)
os.kill(pid, signal.SIGUSR2)

try:
  # p = mp.Process(target=sub, args=[os.getpid()])
  # p.start()
t = mt.Thread(target=sub, args=[os.getpid()])
t.start()
time.sleep(3)
except Exception as e:
print 'except: %s' % e
else:
print 'unexcepted'
finally:
  # p.join()
t.join()


With Python 2.7 I would expect the output:

except: caught sigusr2


but I get:

Traceback (most recent call last):
  File "./bug.py", line 29, in 
print 'unexcepted'
  File "./bug.py", line 13, in sigusr2_handler
raise RuntimeError('caught sigusr2')
  File "./bug.py", line 29, in 
print 'unexcepted'
  File "./bug.py", line 13, in sigusr2_handler
raise RuntimeError('caught sigusr2')
RuntimeError: caught sigusr2



most of the time.  The problem only happens when the 'ctypes.CDLL' line is 
enabled -- commenting it out results in the expected behavior.  That line is 
copied from uuid.py -- importing uuid.py triggers the same unexpected behavior, 
which is ultimately why I am stuck.

Note that the problem only occurs when a *thread* sends the signal -- it does 
*not* happen if the signal is sent by the main thread or by a different process 
(switch to the multiprocessing code path for confirmation).

Interestingly, the problem also disappears when a 'print' statement is added 
after the 'time.sleep(3)', which may (or may not) indicate a timing issue.

I would welcome any suggestion on how to further triage this.

--
components: ctypes
messages: 273889
nosy: Andre Merzky
priority: normal
severity: normal
status: open
title: ctypes interfers with signal handling
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27879] add os.syncfs()

[Josh Rosenberg]

Josh Rosenberg added the comment:

So syncfs is basically "sync, but only for a single file system corresponding 
to a given open file"? Given it's Linux only (doesn't look like it's part of 
any standard that UNIX or BSD OSes would provide), it seems rather special 
purpose to expose in Python. Is there some equivalent API for UNIX/BSD variants 
that `syncfs` could use to provide a single API that works on at least all 
UNIX-like systems? If not, it seems like this is an optimization that doesn't 
generalize; is it worth providing it instead of just having users call os.sync 
and accepting the cost of syncing other file systems?

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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", ))
> +   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

[issue1602] windows console doesn't print or input Unicode

[Christopher Gurnee]

Changes by Christopher Gurnee :


--
nosy: +gurnec

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24254] Make class definition namespace ordered by default

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +fijall

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24254] Make class definition namespace ordered by default

[STINNER Victor]

STINNER Victor added the comment:

Brett Cannon added the comment:
> Any update on this? b1 is exactly 2 weeks away at this point.

Why do we need changes specific to classes, if dictionaries could be ordered by 
default?

Issue #27350: "Compact and ordered dict" by INADA Naoki

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27888] Hide pip install/uninstall windows in setup

[Steve Dower]

Steve Dower added the comment:

An almost immediate update - this patch also makes COMPILEALL not pop up a 
window.

--
Added file: https://bugs.python.org/file44258/installer_2.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Christian Heimes]

Christian Heimes added the comment:

Awesome! I have removed the surplus functions, made the other additional 
functions static and fixed minor test issue with LibreSSL and OpenSSL < 1.0.1. 
My branches on github compile and pass all tests with OpenSSL "0.9.8zc", 
"0.9.8zh", "1.0.1t", "1.0.2", "1.0.2h", "1.1.0" and LibreSSL "2.3.0", "2.4.2" 
on Linux X86_86. I'm using my script https://github.com/tiran/multissl for 
testing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27888] Hide pip install/uninstall windows in setup

[Steve Dower]

New submission from Steve Dower:

The console window for pip that appears during setup prevents us from having a 
truly silent install.

This patch uses the CAQuietExec task from WiX, extracted and checked in 
directly (the binary blob is omitted from the patch), to run the pip 
install/uninstall.

It also makes the task non-vital, which will prevent uninstall from failing 
when pip cannot be removed.

--
assignee: steve.dower
components: Windows
files: installer_1.diff
keywords: patch
messages: 273884
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Hide pip install/uninstall windows in setup
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file44257/installer_1.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Zachary Ware]

Zachary Ware added the comment:

Looks like that took care of it, build succeeded with no new warnings, and 
test.ssltests passed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Christian Heimes]

Christian Heimes added the comment:

Hi Zachary, you have found a bug in my patch. I mistakenly defined 
SSL_CTX_set_default_passwd_cb() and SSL_CTX_set_default_passwd_cb_userdata() 
for OpenSSL < 1.1.0. Both functions already exist. Only the getters are missing 
for < 1.1.0. Please remove both functions from _ssl.c and try again.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24254] Make class definition namespace ordered by default

[Brett Cannon]

Brett Cannon added the comment:

Any update on this? b1 is exactly 2 weeks away at this point.

--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0

[Zachary Ware]

Zachary Ware added the comment:

This will require significant updates to PCbuild/prepare_ssl.py and/or the way 
we build OpenSSL on Windows before we can even properly test this on Windows.  
I don't think that should hold up acceptance of the rest of the patch (provided 
1.0.2 support remains intact), but will need to be handled eventually.

Building on Windows with 1.0.2h is broken with the current patch, but I don't 
understand things well enough to diagnose it:

ssleay.lib(ssl_lib.obj) : error LNK2005: 
_SSL_CTX_set_default_passwd_cb_userdata already defined in _ssl.obj 
[P:\ath\to\cpython\PCbuild\_ssl.vcxproj]

  
ssleay.lib(ssl_lib.obj) : error LNK2005: _SSL_CTX_set_default_passwd_cb already 
defined in _ssl.obj [P:\ath\to\cpython\PCbuild\_ssl.vcxproj]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27427] Add new math module tests

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27870] Left shift of zero allocates memory

[Mark Dickinson]

Mark Dickinson added the comment:

Fixed for 2.7 and 3.6. Closing.

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27870] Left shift of zero allocates memory

[Roundup Robot]

Roundup Robot added the comment:

New changeset 58ea646ef657 by Mark Dickinson in branch '2.7':
Issue #27870: A left shift of zero by a large integer no longer attempts to 
allocate large amounts of memory.
https://hg.python.org/cpython/rev/58ea646ef657

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27870] Left shift of zero allocates memory

[Roundup Robot]

Roundup Robot added the comment:

New changeset 09fa42818cf8 by Mark Dickinson in branch 'default':
Issue #27870: A left shift of zero by a large integer no longer attempts to 
allocate large amounts of memory.
https://hg.python.org/cpython/rev/09fa42818cf8

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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

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

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

[Matthias Klose]

Matthias Klose added the comment:

now fixed.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23968] rename the platform directory from plat-$(MACHDEP) to plat-$(PLATFORM_TRIPLET)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5c77488830bc by doko in branch 'default':
- Issue #23968, keep platform_triplet and multiarch macros in sync
https://hg.python.org/cpython/rev/5c77488830bc

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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", ))
+   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

[issue26040] Improve coverage and rigour of test.test_math

[Jeff Allen]

Jeff Allen added the comment:

Ah, cunning: I can make sense of it in hex.

>>> hex(to_ulps(expected))
'0x3ff0'
>>> hex(to_ulps(got))
'0x3fec'
>>> hex( to_ulps(got) - to_ulps(expected) )
'-0x4'

... and what you've done with ulp then follows.

In my version a format like "{:d} ulps" was a bad idea when the error was a 
gross one, but your to_ulps is only piece-wise linear -- large differences are 
compressed.

I'm pleased my work has mostly survived: here's hoping the house build-bots 
agree. erfc() is perhaps the last worry, but math & cmath  pass on my machine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

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", ))
+   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

[issue27870] Left shift of zero allocates memory

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

--
stage:  -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

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

[issue26040] Improve coverage and rigour of test.test_math

[Jeff Allen]

Jeff Allen added the comment:

Mark: Thanks for doing my homework. Points 1 and 3 I can readily agree with. I 
must take another look at to_ulps() with your patch on locally. I used the 
approach I did because I thought it was incorrect in exactly those corners 
where you prefer it. I'll take a closer look.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27882] Python docs on 9.2 Math module lists math.log2 as function but it does not exist

[Mark Dickinson]

Mark Dickinson added the comment:

Closing. The docs are correct for the corresponding version of Python: 
math.log2 is new in Python 3.3, and the entry for math.log2 is there in Python 
3.3 but not Python 3.2 or Python 2.7.

@PyRW: It looks as though this is simply a version mismatch (looking at the 
wrong docs for the Python version you're using). If you double check 
`sys.version` and find that math.log2 still appears to be missing even on 
Python >= 3.3, feel free to reopen this issue with more information.

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11734] Add half-float (16-bit) support to struct module

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee: mark.dickinson -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25402] More accurate estimation of the number of digits in int to decimal string conversion

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1902e1d79e25 by Mark Dickinson in branch 'default':
Issue #25402: in int-to-decimal-string conversion, reduce intermediate storage 
requirements and relax restriction on converting large integers. Patch by 
Serhiy Storchaka.
https://hg.python.org/cpython/rev/1902e1d79e25

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25402] More accurate estimation of the number of digits in int to decimal string conversion

[Mark Dickinson]

Mark Dickinson added the comment:

Patch and analysis LGTM. Thanks!

--
assignee:  -> mark.dickinson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27803] ctypes automatic byref failing on custom classes attributes

[Erwan Le Pape]

Erwan Le Pape added the comment:

I can confirm Eryk got what I meant. I didn't know if it was meant to work that 
way or if it was simply something that was overlooked so I thought I'd ask, I 
will look into the ctypes code to provide a patch sometime this week if I can.

Terry, for a working example take the following (on a MS Windows):
>>> from ctypes import *
>>> from ctypes.wintypes import *
>>>
>>> class CustomPHKEY(object):
... def __init__(self, value):
... self._as_parameter_ = HKEY(value)
...
>>>
>>> function = ctypes.windll.advapi32.RegOpenKeyExW
>>> function.argtypes = [HKEY, c_wchar_p, DWORD, DWORD, POINTER(HKEY)]
>>> function.restype = LONG
>>> result = CustomPHKEY(0)
>>> function(0x8002, 'SOFTWARE', 0, 0x20019, result)
Traceback (most recent call last):
  File "", line 1, in 
ctypes.ArgumentError: argument 5: : expected 
LP_c_void_p instance instead of c_void_p

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert

[Oren Milman]

Oren Milman added the comment:

Thanks for the review, Mark :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert

[Mark Dickinson]

Mark Dickinson added the comment:

Agreed with the analysis and proposed solution. Thanks!

--
assignee:  -> mark.dickinson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27214] a potential future bug and an optimization that mostly undermines performance in long_invert

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6e1d38674b17 by Mark Dickinson in branch 'default':
Issue #27214: Fix potential bug and remove useless optimization in long_invert. 
Thanks Oren Milman.
https://hg.python.org/cpython/rev/6e1d38674b17

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27877] Add recipe for "valueless" Enums to docs

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: docs@python -> ethan.furman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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 

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

[Mark Dickinson]

Changes by Mark Dickinson :


--
stage:  -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

[Mark Dickinson]

Mark Dickinson added the comment:

In the absence of a concrete use-case, I'm closing as "wont fix". Without 
suitable infrastructure (non-IEEE 754 buildbots, for example) and a clear need 
for this, the effort involved in maintaining CPython on non-IEEE 754 systems 
far outweighs the benefits.

--
assignee:  -> mark.dickinson
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27870] Left shift of zero allocates memory

[Mark Dickinson]

Mark Dickinson added the comment:

Updated patch, breaking out the implementation-specific tests into their own 
method. (Thanks, Serhiy!)

--
Added file: https://bugs.python.org/file44256/lshift_zero_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27870] Left shift of zero allocates memory

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27870] Left shift of zero allocates memory

[Mark Dickinson]

Mark Dickinson added the comment:

Here's a patch against 3.6. I think this probably shouldn't be changed for 3.5, 
but it may be worth backporting the fix to 2.7.

--
keywords: +patch
Added file: https://bugs.python.org/file44255/lshift_zero.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27870] Left shift of zero allocates memory

[Mark Dickinson]

Mark Dickinson added the comment:

Also applies to 3.x. Working on a fix.

--
assignee:  -> mark.dickinson
versions: +Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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: 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

Nikola 7.8.0 released!

[Roberto Alsina]

On behalf of the Nikola team, I am pleased to announce the immediate
availability of Nikola v7.8.0. It fixes some bugs and adds new features.
What is Nikola?

Nikola is a static site and blog generator, written in Python. It can use
Mako and Jinja2 templates, and input in many popular markup formats, such
as reStructuredText and Markdown — and can even turn Jupyter (IPython)
Notebooks into blog posts! It also supports image galleries, and is
multilingual. Nikola is flexible, and page builds are extremely fast,
courtesy of doit (which is rebuilding only what has been changed).

Find out more at the website: https://getnikola.com/
Downloads

Install using pip install Nikola or download tarballs on GitHub
 and PyPI
.
ChangesFeatures

   - Exposed gist as a shortcode (Issue #2459)
   - Always copy source files for listings (Issue #2473)
   - Detect dependencies in template strings (Issue #2455)
   - RSS feeds for sections (Issue #2068)
   - New data metadata that loads data from external files (Issue #2450)
   - Shortcode to escape to the template language (Issue #1227)
   - Added link to raw file in listings (Issue #1995)
   - New NO_DOCUTILS_TITLE_TRANSFORM (Issue #2382)
   - Update options of chart directive to Pygal 2.2.3
   - Pass global context to template shortcodes (Issue #2424)
   - Added new options --html2text and --transform-to-markdown to WordPress
   importer (Issue #2261)
   - Listing: guess the lexer if cannot be determined from the file name.
   - Read files from data/ and insert data in global context (Issue #2477)

Bugfixes

   - Added link to sources in the output of listing directive (Issue #2472)
   - Fix Windows crash with calendar locales (Issue #2332)
   - Remove the (useless)  tag by default; change conf.py to opt in
   (Issue #2471)
   - Show tag descriptions when TAG_PAGES_ARE_INDEXES is True (Issue #2444)
   - Record template dependencies for post-list shortcut (Issue #2451)
   - Default to English for docutils messages if no translations exist
   (Issues #2422, #2437)
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

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: 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?

[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: 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

[issue27818] Speed up number format spec parsing

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9bddf9e72c96 by Serhiy Storchaka in branch 'default':
Issue #27818: Speed up parsing width and precision in format() strings for
https://hg.python.org/cpython/rev/9bddf9e72c96

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23229] add inf, nan, infj, nanj to cmath module

[Mark Dickinson]

Changes by Mark Dickinson :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23229] add inf, nan, infj, nanj to cmath module

[Mark Dickinson]

Changes by Mark Dickinson :


--
resolution:  -> fixed
stage: commit review -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23229] add inf, nan, infj, nanj to cmath module

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4b25da63d1d0 by Mark Dickinson in branch 'default':
Issue 23229: add cmath.inf, cmath.nan, cmath.infj and cmath.nanj.
https://hg.python.org/cpython/rev/4b25da63d1d0

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27818] Speed up number format spec parsing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I haven't found my old patch and tried to reimplement it. Added new file in 
stringlib. The original patch speeds up microbenchmarks only on about 4% on my 
computer (32-bit Linux). This is small, but the patch is simple. Moving some 
functions to template file adds yet about 2%. This is too small for adding new 
file. Thus I'll commit the original patch, with small style changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

One more version; increased the default ulp_tol to 5 everywhere, and made some 
minor style fixes in nearby code.

--
Added file: https://bugs.python.org/file44254/iss26040_v4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

I've reviewed the test_math portion of the patch (which looks good, thank 
you!), and made a few revisions in iss26040_v3.patch.

1. I've rewritten the ulp() function to use struct. Same behaviour as before, 
but this way feels safer, since it doesn't rely on the exact form of the 
float.hex format.

2. I've reworked the ulp-based comparison to use the old to_ulps function, 
instead of basing it on ulp(). That's mostly just a personal preference: I 
prefer the symmetry of the abs(to_ulps(got) - to_ulps(expected)) form, and I 
think it behaves slightly better at or near powers of two. (If expected == 1.0 
and got == 1.0 - 2**-51, I want that to be seen as 4 ulps error rather than 2.)

3. I increased the default ulp tolerance to 5 ulps, and increased the ulps 
tolerance for some of the special cases. There are some badly behaved libm 
implementations out there, and I don't want to break more buildbots than 
necessary.

--
Added file: https://bugs.python.org/file44253/iss26040_v3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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?

[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

[issue27861] sqlite3 type confusion and multiple frees

[Roundup Robot]

Roundup Robot added the comment:

New changeset c046cbb24f98 by Serhiy Storchaka in branch '3.5':
Issue #27861: Fixed a crash in sqlite3.Connection.cursor() when a factory
https://hg.python.org/cpython/rev/c046cbb24f98

New changeset 97dbba8a6d4a by Serhiy Storchaka in branch '2.7':
Issue #27861: Fixed a crash in sqlite3.Connection.cursor() when a factory
https://hg.python.org/cpython/rev/97dbba8a6d4a

New changeset afcec2d11e9e by Serhiy Storchaka in branch 'default':
Issue #27861: Fixed a crash in sqlite3.Connection.cursor() when a factory
https://hg.python.org/cpython/rev/afcec2d11e9e

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[issue27887] Installation failed

[SilentGhost]

Changes by SilentGhost :


--
resolution:  -> not a bug
stage:  -> resolved
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27887] Installation failed

[Aleksandar Petrovic]

Changes by Aleksandar Petrovic :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27877] Add recipe for "valueless" Enums to docs

[John Hagen]

John Hagen added the comment:

Emanuel, I like your rewording.  Uploaded a new patch incorporating it.

--
Added file: https://bugs.python.org/file44252/issue27877.johnthagen.02.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27877] Add recipe for "valueless" Enums to docs

[John Hagen]

Changes by John Hagen :


Removed file: https://bugs.python.org/file44249/issue27877.johnthagen.01.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Twisted 16.4.0 Release Announcement

[Amber "Hawkie" Brown]

On behalf of Twisted Matrix Laboratories, I am honoured to announce the release 
of Twisted 16.4.0.

The highlights of this release are:

- twist, a new command line tool for running Twisted plugins, similar to twistd 
but with a simpler, cleaner interface.
- A new interface for Protocols, IHandshakeListener, which tells Twisted to 
tell the Protocol when the TLS handshake has been completed.
- async/await support for Deferreds, allowing you to write Python 3.5+ 
coroutines using Twisted
- Trial can be invoked with "python -m twisted.trial".
- All Twisted executables (trial, twistd, etc) are now Setuptools console 
scripts, meaning they will work much better on Windows.
- 35+ more modules ported to Python 3, and many many cleanups on the way to 
Python 3 on Windows support.
- All the security fixes of Twisted 16.3.1 + 16.3.2 (httpoxy, HTTP session 
identifier strengthening, HTTP+TLS consuming sockets)
- 240+ closed tickets overall.

For more information, check the NEWS file (link provided below).

You can find the downloads at > (or alternatively 
>). The NEWS file is also 
available at >.

Many thanks to everyone who had a part in this release - the supporters of the 
Twisted Software Foundation, the developers who contributed code as well as 
documentation, and all the people building great things with Twisted!

Twisted Regards,
Amber Brown (HawkOwl)

PS: Twisted 16.4.1 will be coming soon after this with a patch mitigating 
SWEET32, by updating the acceptable cipher list.


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue27861] sqlite3 type confusion and multiple frees

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26040] Improve coverage and rigour of test.test_math

[Mark Dickinson]

Mark Dickinson added the comment:

iss26040.patch didn't apply cleanly to master (because of the recent math.tau 
addition). Here's an updated patch.

--
Added file: https://bugs.python.org/file44251/iss26040_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com