Age | Commit message (Collapse) | Author | Files | Lines |
|
Python 2 support was retained for use with --enable-python=system
on RHEL7 and SLES. The time has arrived to remove it.
Some .py files that were imported from third parties are not changed to
enable easier replacement with updated versions if necessary.
solenv/gdb should continue to support Python 2.
bin/get-bugzilla-attachments-by-mimetype requires Python 2 to access
Launchpad.
Change-Id: I26414ae8e9f8402c90336af82020135685694217
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91697
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: Idf2e8567a154b25b1625b9cd1651bd77cc684859
Reviewed-on: https://gerrit.libreoffice.org/80116
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Change-Id: I1dcb41b404d69e7437a2cc6f22d3391bb91f3acc
Reviewed-on: https://gerrit.libreoffice.org/69216
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
After b9757f5cfdb62b24e79eeb4c0ef0c8b98056cecf "loplugin:useuniqueptr in
vcl/svdata" ASan/UBSan builds started to fail (like
<https://ci.libreoffice.org//job/lo_ubsan/1025/>) at the end of
PythonTest_dbaccess_python (and probably other PythonTests), when during exit
the static utl::ConfigManager instance already happens to be destroyed by the
time the static ImplSVData's mpSettingsConfigItem is destroyed (which would
normally be cleared during DeInitVCL, if PythonTests would call that, and which
in the past had thus simply been leaked in PythonTests when that
mpSettingsConfigItem was a plain pointer instead of std::unique_ptr).
So ensure that PythonTests that initialize VCL also call DeInitVCL, via a new
private_deinitTestEnvironment, complementing the existing
private_initTestEnvironment.
However, while private_initTestEnvironment is called once (typically via
UnoInProcess.setUp, which internally makes sure to only call it once) as soon as
the first executed test needs it, private_deinitTestEnvironment must be called
once after the lasts test needing it has executed. The only way that I found to
do that is to override unittest.TextTestResult's stopTestRun method, which is
called once after all tests have been executed. Hence a new test runner setup
in unotest/source/python/org/libreoffice/unittest.py that is now called from
solenv/gbuild/PythonTest.mk.
That revealed a few places in PythonTests that didn't yet close/delete documents
that they had opened, which has now been added.
One remaining problem then is that classes like SwXTextDocument and friends call
Application::GetSolarMutex from their dtors, via sw::UnoImplPtrDeleter (a "Smart
pointer class ensuring that the pointed object is deleted with a locked
SolarMutex", sw/inc/unobaseclass.hxx). That means that any PyUNO proxies to
such C++ objects that remain alive after private_deinitTestEnvironment will
cause issues at exit, when Python does a final garbage collection of those
objects. The ultimate fix will be to remove that unhelpful UnoImplPtrDeleter
and its locking of SolarMutex from the dtors of UNO objects; until then, the
Python code is now sprinkled with some HACKs to make sure all those PyUNO
proxies are released in a timely fashion (see the comment in
unotest/source/python/org/libreoffice/unittest.py for details). (Also, it would
probably help if UnoInProcess didn't keep a local self.xDoc around referencing
(just) the last result of calling one of its open* methods, confusingly making
it the responsibility of UnoInProcess to close that one document while making it
the responsibility of the test code making the other UnoInProcess.open* calls to
close any other documents.)
Change-Id: Ief27c81e2b763e9be20cbf3234b68924315f13be
Reviewed-on: https://gerrit.libreoffice.org/60100
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after d76281864b0e83812c0edf7490b1e8271e89fff5 "Create temp copies of test
docs in Python/UITests"
Change-Id: I0f331ca9567e9a54842cc35b35628046d29b176d
Reviewed-on: https://gerrit.libreoffice.org/52470
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...where necessary, so the tests will succeed if SRCDIR is a read-only tree.
Change-Id: Iea4c52d5982d3eba079088ef1670ff557ce30c3f
Reviewed-on: https://gerrit.libreoffice.org/52122
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...where the original code caused an "Unsupported URL <file://C%3A/...>" error,
while just using pathname2url instead of quote caused "Unsupported URL
<file:///C://...>", so had to add the silly re.sub. Hopefully keeps working
with all sorts of Python 2 and 3 that we want to support. (And is there really
no better way to convert a pathname to a file URL in Python?)
Change-Id: I43f450707fe5206a1e6b91918962d2d90a880463
Reviewed-on: https://gerrit.libreoffice.org/43092
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...instead of once for each class derived from CollectionsTestBase (as listed in
pyuno/PythonTest_pyuno_pytests_testcollections.mk), causing the
assert(!pSVData->maDeInitHook.IsSet());
in Application::setDeInitHook (vcl/source/app/svapp.cxx) to fire.
This is probably far from being idiomatic Python code...
Change-Id: I8cd1470c085b16b7b82468a308cfd1dead2db034
|
|
implemented
Change-Id: Id42e9a2e2cfd7c95140411123e8702dfdb4054da
Reviewed-on: https://gerrit.libreoffice.org/31676
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
Change-Id: I5d35305386e1f520d1030776e2b7bcf7620eda04
Reviewed-on: https://gerrit.libreoffice.org/22514
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
- Simplifies working with UNO objects by giving the behaviour of
Python lists, dicts and iterators to objects which implement UNO
container interfaces
- Applies a custom behaviour to allow objects which implement
com::sun::star::table::XCellRange to yield cells and cell ranges by
subscript
- When UNO container objects are addressed in the new style,
eliminates the requirement to manually construct Any objects for
contained elements which are typed sequences
- Allows lists and iterators to be passed wherever a UNO method
accepts a sequence
- Relaxes the requirements for initialising UNO structs to allow
some members to be skipped when all initialisers are passed by name
1. Collection interfaces
========================
Objects which implement core UNO collection interfaces are made to
behave in a way that is more natural for Python code.
com::sun::star::container::XIndexAccess
com::sun::star::container::XIndexReplace
com::sun::star::container::XIndexContainer
- Objects provide Python list access semantics
num = len(obj) # Number of elements
val = obj[0] # Access by index
val1,val2 = obj[2:4] # Access by slice
val1,val2 = obj[0:3:2] # Access by extended slice
if val in obj: ... # Test value presence
for val in obj: ... # Implicit iterator (values)
itr = iter(obj) # Named iterator (values)
obj[0] = val # Replace by index
obj[2:4] = val1,val2 # Replace by slice
obj[0:3:2] = val1,val2 # Replace by extended slice
obj[2:3] = val1,val2 # Insert/replace by slice
obj[2:2] = (val,) # Insert by slice
obj[2:4] = (val,) # Replace/delete by slice
obj[2:3] = () # Delete by slice (implicit)
del obj[0] # Delete by index
del obj[2:4] # Delete by slice
com::sun::star::container::XNameAccess
com::sun::star::container::XNameReplace
com::sun::star::container::XNameContainer
- Objects provide Python dict access semantics
num = len(obj) # Number of keys
val = obj[key] # Access by key
if key in obj: ... # Test key presence
for key in obj: ... # Implicit iterator (keys)
itr = iter(obj) # Named iterator (keys)
obj[key] = val # Replace by key
obj[key] = val # Insert by key
del obj[key] # Delete by key
com::sun::star::container::XEnumerationAccess
- Objects provide Python iterable semantics
for val in obj: ... # Implicit iterator
itr = iter(obj) # Named iterator
com::sun::star::container::XEnumeration
- Objects provide Python iterator semantics
for val in itr: ... # Iteration of named iterator
if val in itr: ... # Test value presence
Objects which implement both XIndex* and XName* are supported, and
respond to both integer and string keys. However, iterating over
such an object will return the keys (like a Python dict) rather than
the values (like a Python list).
2. Cell ranges
==============
A custom behaviour is applied to objects which implement
com::sun::star::table::XCellRange to allow their cells and cell
ranges to be addressed by subscript, in the style of a Python list
or dict (read-only). This is applicable to Calc spreadsheet sheets,
Writer text tables and cell ranges created upon these.
cell = cellrange[0,0] # Access cell by indices
rng = cellrange[0,1:2] # Access cell range by index,slice
rng = cellrange[1:2,0] # Access cell range by slice,index
rng = cellrange[0:1,2:3] # Access cell range by slices
rng = cellrange['A1:B2'] # Access cell range by descriptor
rng = cellrange['Name'] # Access cell range by name
Note that the indices used are in Python/C order, and differ from
the arguments to methods provided by XCellRange.
- The statement cellrange[r,c], which returns the cell from row r
and column c, is equivalent to calling
XCellRange::getCellByPosition(c,r)
- The statement cellrange[t:b,l:r], which returns a cell range
covering rows t to b(non-inclusive) and columns l to r(non-
inclusive), is equivalent to calling
XCellRange::getCellRangeByPosition(l,t,r-1,b-1).
In contrast to the handling of objects implementing XIndex*,
extended slice syntax is not supported. Negative indices (from-end
addresses) are supported only for objects which also implement
com::sun::star::table::XColumnRowRange (currently Calc spreadsheet
sheets and cell ranges created upon these). For such objects, the
following syntax is also available:
rng = cellrange[0] # Access cell range by row index
rng = cellrange[0,:] # Access cell range by row index
rng = cellrange[:,0] # Access cell range by column index
3. Elimination of explicit Any
==============================
PyUNO has not previously been able to cope with certain method
arguments which are typed as Any but require a sequence of specific
type to be passed. This is a particular issue for container
interfaces such as XIndexContainer and XNameContainer.
The existing solution to dealing with such methods is to use a
special method to pass an explicitly typed Any, giving code such as:
index = doc.createInstance("com.sun.star.text.ContentIndex");
...
uno.invoke( index.LevelParagraphStyles , "replaceByIndex",
(0, uno.Any("[]string", ('Caption',))) )
The new Pythonic container access is able to correctly infer the
expected type of the sequences required by these arguments. In the
new style, the above call to .replaceByIndex() can instead be
written:
index.LevelParagraphStyles[0] = ('Caption',)
4. List and iterator arguments
==============================
Wherever a UNO API expects a sequence, a Python list or iterator can
now be passed. This enables the use of list comprehensions and
generator expressions for method calls and property assignments.
Example:
tbl = doc.createInstance('com.sun.star.text.TextTable')
tbl.initialize(10,10)
# ... insert table ...
# Assign numbers 0..99 to the cells using a generator expression
tbl.Data = ((y for y in range(10*x,10*x + 10)) for x in range(10))
5. Tolerant struct initialisation
=================================
Previously, a UNO struct could be created fully uninitialised, or by
passing a combination of positional and/or named arguments to its
constructor. However, if any arguments were passed, all members were
required to be initialised or an exception was thrown.
This requirement is relaxed such that when all arguments passed to a
struct constructor are by name, some may be omitted. The existing
requirement that all members must be explicitly initialised when
some constructor arguments are unnamed (positional) is not affected.
Example:
from com.sun.star.beans import PropertyValue
prop = PropertyValue(Name='foo', Value='bar')
Change-Id: Id29bff10a18099b1a00af1abee1a6c1bc58b3978
Reviewed-on: https://gerrit.libreoffice.org/16272
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Matthew Francis <mjay.francis@gmail.com>
|
|
Change-Id: I7e619daf8743d3471ece72d81f6cf1bb61741646
|
|
Change-Id: Idad0ba862da7317b5824f1bfb400d05cef105b7f
|
|
I'm still suspicious
Change-Id: I56bfbe1ea2f92ffba6264b7543fa5df7f29f2bd0
|
|
Change-Id: I6000620bec95f32ec357a3e56e14f3255da978af
|
|
Change-Id: Ia2dad214e6a224c979a8664bfded7d2caffb221a
|
|
The bug in question crashed LibO when inserting a group of cells.
This bug was quashed, per se, by commit
07e2c31831ad265b018e5fdf59bdde048fbb4d35, but it occurs to me that at
least the particular functionality of inserting a group of cells could
use more testing.
Change-Id: Icdbfff86fb0265eef325bcc94d9fc9f3e9e38413
|