date:20170309

[issue29768] Fix expact version check

2017-03-09 Thread Serhiy Storchaka


Changes by Serhiy Storchaka :


--
pull_requests: +473

___
Python tracker 

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

[issue29768] Fix expact version check

2017-03-09 Thread Serhiy Storchaka


Changes by Serhiy Storchaka :


--
pull_requests: +474

___
Python tracker 

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

[issue29768] Fix expact version check

2017-03-09 Thread Serhiy Storchaka


Changes by Serhiy Storchaka :


--
pull_requests: +475

___
Python tracker 

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

[issue29768] Fix expact version check

2017-03-09 Thread Serhiy Storchaka


Changes by Serhiy Storchaka :


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

[issue29758] Previously-working SWIG code fails in Python 3.6

2017-03-09 Thread STINNER Victor


STINNER Victor added the comment:

Which function raises this exception? Add the traceback place. It may be a
bug in your code.

--

___
Python tracker 

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

[issue29758] Previously-working SWIG code fails in Python 3.6

2017-03-09 Thread Tristan Croll


Tristan Croll added the comment:

OK, a further clue. First, a little more detail on how my project is arranged 
(to re-iterate, this works without complaint in Python 3.5):

Rather than use my SWIG output directly, I've created a further wrapper layer 
in Python to add functions/syntactic sugar that would be difficult to achieve 
in SWIG, add a bit of extra documentation, and bury some classes that may be 
occasionally useful but don't really need to be in the primary API. The SWIG 
output Python library I name clipper_core, and I use the following class 
decorators for classes in the front-end API to reduce the amount of code 
(Python and SWIG) needed:

def mappedclass(old_cls):
'''
Ensures that objects returned from functions in the clipper_core
library are instantiated in Python as the derived class with the
extra functionality. 
'''
def decorator(cls):
def __newnew__(thiscls, *args, **kwargs):
if thiscls == old_cls:
return object.__new__(cls)
return object.__new__(thiscls)
old_cls.__new__ = __newnew__

return cls
return decorator
 
def getters_to_properties(*funcs):
'''
Class decorator. Add the names of any getter functions with void 
arguments (e.g. Coord_grid.u()) to convert them to properties. If
you want the property name to be different from the function name,
add the desired name and the function name as a tuple 
(e.g. ('uvw', '_get_uvw'))
'''
def property_factory(func):
def getter(self):
return getattr(super(self.__class__, self), func)()
prop = property(getter)
return prop

def decorator(cls):
for func in funcs:
if type(func) == tuple:
setattr(cls, func[0], property_factory(func[1]))
else:
setattr(cls, func, property_factory(func)) 
return cls
return decorator

def format_to_string(cls):
'''
Class decorator to redirect the Clipper format() function to __str__,
to provide pretty printing of the object.
'''
def format(self):
return super(self.__class__,self).format()
def __str__(self):
return self.format
setattr(cls, 'format', property(format))
setattr(cls, '__str__', __str__)
return cls

Experimenting this morning with the following two classes:

@format_to_string
@mappedclass(clipper_core.Cell_descr)
class Cell_descr(clipper_core.Cell_descr):
def __init__(self, abc, angles):
'''
__init__(self, abc, angles) -> Cell_descr

Args:
abc ([float*3]): cell dimensions in Angstroms
angles ([float*3]): alpha, beta and gamma angles in degrees
'''
clipper_core.Cell_descr.__init__(self, *abc, *angles)

@format_to_string
@getters_to_properties('cell_descr', 'matrix_frac', 'matrix_orth', 
   'metric_real', 'metric_reci', 'volume')
@mappedclass(clipper_core.Cell)
class Cell(clipper_core.Cell):
'''
Define a crystallographic unit cell using the lengths of the three
sides a, b, c (in Angstroms) and the three angles alpha, beta, gamma
(in degrees). 
'''
def __init__(self, abc, angles):
'''
__init__(self, abc, angles) -> Cell

Args:
abc ([float*3]): cell dimensions in Angstroms
angles ([float*3]): alpha, beta and gamma angles in degrees
'''
cell_descr = Cell_descr(abc, angles)
#cell_descr = clipper_core.Cell_descr(*abc, *angles)
clipper_core.Cell.__init__(self, cell_descr)

def __eq__(self, other):
return self.equals(other)

Then:
import clipper
cell = clipper.cell([100,100,100],[90,90,90])
cell.cell_descr

SystemError   Traceback (most recent call last)
 in ()
> 1 c.cell_descr

/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/clipper/clipper_decorators.py
 in getter(self)
 87 def property_factory(func):
 88 def getter(self):
---> 89 return getattr(super(self.__class__, self), func)()
 90 prop = property(getter)
 91 return prop

/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/clipper/lib/clipper_python_core/clipper.py
 in cell_descr(self)
   8249 
   8250 """
-> 8251 return _clipper.Cell_cell_descr(self)
   8252 
   8253 __swig_destroy__ = _clipper.delete_Cell

SystemError: Objects/tupleobject.c:81: bad argument to internal function

... but if I comment out the derived Cell_descr class and switch to the 
alternate cell_descr constructor in Cell.__init__(), then it works as expected. 
I have tried commenting out the other class decorators, with no effect - so it 
would seem it's what's happening in the @mappedclass decorator that is causing 
my troubles.

--

___
Python tracker

[issue20087] Mismatch between glibc and X11 locale.alias

2017-03-09 Thread Marc-Andre Lemburg

Marc-Andre Lemburg added the comment:

On 09.03.2017 08:15, Benjamin Peterson wrote:
> 
> "eo_XX" is just something that appears in the X11 locale.alias file. My 
> change doesn't add that; it was already there. (for Esperanto, which I 
> suppose explains the "XX")

Yes, I know. That was an example of a bug in the X.org list.

> Most of the changes you identify the glibc aliases taking precedence over the 
> X11 ones. e.g., glibc has "fi_FI ISO-8859-1" while the X11 locale list has 
> "fi_FI.ISO8859-15". That seems correct to me as far as the intent of this 
> change is concerned.

No, it's not correct. ISO-8859-1 is the older version of Latin-1
without the Euro sign. ISO8859-15 adds it.

> How do you propose to pick and choose what we use from the X11 locale alias 
> list?

We have to go through the list one by one to check whether
the mapping update makes sense and is correct.

This will be difficult in a few cases where the glibc mapping
switches to UTF-8 from an ISO encoding. We'll have to find
evidence that this change does indeed make sense.

My take on this is that the X.org folks know better than the
glibc folks, since the former have to deal with end users that
rely on the locale settings a lot more than applications
using glibc for getting an initial locale setting right.

Also note that you are parsing the SUPPORTED file from
glibc (in slightly processed form):

https://github.com/bminor/glibc/blob/master/localedata/SUPPORTED

This file does not provide a locale alias mapping as
the routine in makelocalealias.py suggests. Instead it's
a list of locales to install by default:

https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/localedata/Makefile

In glibc you can define both the locale and the encoding separately
when creating a locale using localedef and the file simply provides
the default parameters to pass to this tool.

As such, I don't see how you can derive a default alias
meaning from the file.

It's simply an indication of what glibc would have installed
in case it were installed from source, but that's hardly ever
the case. On today's systems only a bare subset of locales
is installed and more added as necessary, so you rarely have
all the locales defined in SUPPORTED installed on a system.

So the file doesn't even provide a hint at what could
be installed on the system ("locale -a" gives you that list).

Here's the history:

https://github.com/bminor/glibc/commits/master/localedata/SUPPORTED

It's merely a list of additions and removals from the
default set. Nothing more. It does provide a list of
known and supported locales, but no usable or authoritative
encoding information (locales are defined using Unicode, so
the encoding is a parameter and not predefined).

Overall, I believe the file is pretty useless to use as
basis for an alias table providing encoding information.
It may provide some ideas for corrections, but should not
override the X.org one by default.

On the other hand, you have the local.alias master file:

https://cgit.freedesktop.org/xorg/lib/libX11/tree/nls/locale.alias.pre

together with the history of why changes were made and when.
This is an authoritative resource and people are making changes
against it from the user perspective.

I'd suggest to make the override optional in makelocalealias.py
via a command line switch and to use this for manually adding
or fixing X.org entries.

If you absolutely want to parse the glibc file per default as
well, please only let it add new entries, not override existing
ones. As we've seen in the patch, those overrides need to be
carefully reviewed.

--

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

2017-03-09 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

> Why is the X11 locale alias map used at all? It seems like it can only create 
> confusion with libc.

Originally only the X11 locale alias map was used. The support of the glibc 
locale alias map was added 2.5 years ago (issue20079).

--

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

2017-03-09 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

The SUPPORTED file from glibc is used for determining the default encoding  for 
locales that don't include it explicitly. For example en_IN uses UTF-8 rather 
than ISO8859-1.

--

___
Python tracker 

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

[issue29769] pkgutil._iter_file_finder_modules should not be fooled by *.py folders

2017-03-09 Thread Wolfgang Maier


New submission from Wolfgang Maier:

The current implementation of _iter_file_finder_modules parses folders with a 
valid Python module extension as modules (e.g. it would report a *folder* xy.py 
as a module xy).
As a result, e.g., pydoc.apropos('') fails if such a folder is found anywhere 
on sys.path.

I'm attaching a patch that fixes this and also brings a few minor improvements 
(like using a set instead of a dict with 1 values and reusing the function in 
ImpImporter).

However, I have a question about it (which is also the reason why I didn't turn 
this into a PR right away): in addition to checking that an item detected as a 
module is not a directory, I think it would be good to also check that an 
__init__ module inside a possible package really is a file. If I uncomment the 
respective check in the patch though, I'm getting a test_pydoc failure because 
the test creates a package directory with no access to contained file 
attributes. So even though there is an __init__.py file in the package dir the 
isfile() check fails. I think that should, in fact, happen and the pydoc test 
is wrong, but apparently whoever wrote the test had a different opinion.
Any thoughts?

--
components: Library (Lib)
files: pkgutil.patch
keywords: patch
messages: 289285
nosy: ncoghlan, wolma
priority: normal
severity: normal
status: open
title: pkgutil._iter_file_finder_modules should not be fooled by *.py folders
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file46714/pkgutil.patch

___
Python tracker 

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

[issue20087] Mismatch between glibc and X11 locale.alias

2017-03-09 Thread Marc-Andre Lemburg

Marc-Andre Lemburg added the comment:

On 09.03.2017 11:47, Serhiy Storchaka wrote:
>
> The SUPPORTED file from glibc is used for determining the default encoding
> for locales that don't include it explicitly. For example en_IN uses UTF-8
> rather than ISO8859-1.

No, the glibc locales don't say anything about default encodings
used in a locale:

http://manpages.ubuntu.com/manpages/wily/en/man5/locale.5.html

These encodings are just used for determining the default
set of locale.encoding variants to install on the system,
nothing more:

https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/localedata/Makefile#L204

glibc does have a locale.alias file:

https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/intl/locale.alias

which uses the X.org format, but this is completely out of
date and declared obsolete.

Serhiy: If you believe that there's anything authoritative about
the glibc SUPPORTED file in terms of defining the commonly
used encoding in a locale, please provide references. These
should also clarify why the glibc encoding is the correct one
compared to the X.org mapping.

It doesn't help, trying to interpret things into such build
files. We need a database that is being actively maintained
and has a track record of representing what people actually
use in their locales. The only one I know is the X.org one.

94 matches

Mail list logo