Michael Felt added the comment:
OK - merely added some fprintf statements.
When it is working as expected, the k->type values seem to be between 500 and
535 - when it fails the k->type value is frequently 9 digits (e.g., 537120904)
- and it seems to never become -1 -- which would e
Michael Felt added the comment:
Thanks Kevin.
I took your patch (added your name to blurb as well).
Only difference was to remove Qsystem (or something), from the pathnames.
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.
Michael Felt added the comment:
Iirc, my debug shows that k is not NULL, as k++ is not going to suddenly become
smaller. And my debug shows it grows by a constant.
My gut says the pointer to the base of the tokens is wrong, because the key
types are such different values. Or do you know
Michael Felt added the comment:
My apologies for lack of context.
On 05/07/2020 20:27, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> Unfortunately, I am having a hard time parsing your error description because
> is not immediate to distinguish:
&
Michael Felt added the comment:
Thanks for getting back to this. ++1 :)
On 25/06/2020 11:49, Serhiy Storchaka wrote:
> Serhiy Storchaka added the comment:
>
> test_bdb fails on non-UTF-8 locale because Python executes a Python code from
> the corresponding "encodings"
Michael Felt added the comment:
Glad you figured it out!
I doubt I would have. Thx!!
On 06/07/2020 14:37, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> This is enough to reproduce the problem:
>
> #include
>
> typedef struct {
> c
Michael Felt added the comment:
On 06/07/2020 16:35, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
>> Glad you figured it out!
> Well, this is not over ;)
>
> We should confirm that this is either a bug in XLC or a violation of C99
probably a
Michael Felt added the comment:
I tried check.c and check_bad.c using xlc-v11 (on my POWER6) - and the
results were the same as in Pablo's entry.
On the gcc119 host - using the v13 compiler, check_bad does not crash.
Not gotten to testing xlc-v16 yet.
I have seen lots of options
Michael Felt added the comment:
Note: - two different systems, different HW, different OS levels.
xlc-v11, master : commit deb016224cc506503fb05e821a60158c83918ed4 (HEAD
-> master, upstream/master, upstream/HEAD)
Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../
Michael Felt added the comment:
I also tested xlC v16, and then it just hung, for hours - while all of you were
being more productive.
I’ll kickoff my bot again, and see how it goes.
Sent from my iPhone
> On 6 Jul 2020, at 21:31, miss-islington wrote:
>
>
> miss-islingto
Michael Felt added the comment:
I saw the mails last night and restarted my bot - it still fails.
Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
know asap.
Yes - expecting 3.8 and 3.7 to build, but want to be sure.
On 06/07/2020 23:34, Pablo Galindo Salgado wrote
Michael Felt added the comment:
On 07/07/2020 11:12, Michael Felt wrote:
> Michael Felt added the comment:
>
> I saw the mails last night and restarted my bot - it still fails.
> Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
3.7, 3.8 and 3.9 built, mas
Michael Felt added the comment:
Here is the stack trace - still during initialization: And in "ceval.c,
but dbx does not like how the 'h files are being used: line 941 and 659
lines don't match :(
(dbx) list
"object.h" has only 659 lines
Segmentation fault in _PyEval
Michael Lazar added the comment:
Greetings,
I just encountered this issue [0] and I agree with the sentiment that the
documentation is currently misleading.
Particularly,
> By default, it provides access to the same database as the rest of this
> module. The initial database is a c
New submission from Michael Felt :
issue41069 introduces tests for paths/files containing non-ascii characters.
On AIX - since the merge of PR21035 and PR21156 - the bots have been broken,
i.e., returning test failed.
commit 700cfa8c90a90016638bac13c4efd03786b2b2a0
Author: Serhiy Storchaka
Michael Felt added the comment:
I am taking a look at these, and I am sure there is a PEP I am unaware of - atm
- so, a quick question.
Is the double space at the end of a sentence 'required' by the rst processing,
or is this also a 'personal' writing style in some o
Michael Felt added the comment:
Neat! extra arguments!!
The warnings - extracted:
== CPython 3.10.0a0 (heads/master-dirty:b1a8730, Jul 26 2020, 14:00:34) [GCC
7.2.0]
== AIX-2-00F9C1964C00-powerpc-32bit big-endian
== cwd: /home/aixtools/cpython/cpython-master/build/test_python_27984450
Michael Felt added the comment:
Thanks. afaik, double spacing is a 'feature' a programmer added to a
text processing language - of the WYSIWUG kind, because program's such
as troff/nroff
didn't need them. They, rather it, understood that a period followed by
a space in
Change by Michael Felt :
--
keywords: +patch
pull_requests: +20780
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21639
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
Excellent!!
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git pr 21640
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 58 (delta 46), reused 48 (delta 46
Michael Felt added the comment:
The 'master' branch bot is working again, the 3.9 branch is still broken, and
the 3.8 branch seems, as yet, unaffected.
--
___
Python tracker
<https://bugs.python.o
New submission from Michael Felt :
Two tests in test_pathlib test that the files created have mode o666 (rw-rw-rw).
However, on a filesystem (in my case NFS) configured to never permit global
write - the test will always fail.
Is this something to be concerned about?
I can think of a few
Michael Felt added the comment:
If #19521 had been merged I would be all for closing this as a duplicate.
However, if i have read all the comments correctly noone has tested the other
pr.
As the approaches are quite different I think both should be open until a
decision is made on the
Michael Felt added the comment:
As much as I wish I had the skills to do the cherry picking - I am not going to
touch this.
The AIX bots for 3.9 branch continue to report broken for test_io (ENV change)
- as they still wait for the backport for that branch
New submission from Michael Mussato :
Wouldn't it be helpful if the pdb showed the path to the current breakpoint as
a clickable link? For this to work, it seems that the path needs to follow a
specific format, like so:
"File "/full/path/to/file.py", line XY"
C
Change by Michael Mussato :
--
title: pdb - Clickabler path to breakpoints -> pdb - Clickable path to
breakpoints
___
Python tracker
<https://bugs.python.org/issu
New submission from Michael Pelletier :
This emerged during a fault in a fileserver mounted on a Linux machine via a
Samba client mount. The access to the mountpoint was being blocked by the
fileserver, but os.access() wasn't able to recognize it as unreadable:
>>> os.acc
New submission from Michael Felt :
Successfully built and packaged the Python-3.9.0 distribution tar archive
without modification - as 32-bit.
Repeating the same process with the following environment change:
# export OBJECT_MODE=64
fails with a segmentation fault by the "first-
New submission from Michael Ferguson :
I have been trying to create a wrapper script for `python3` in a venv that
behaves similarly to a symbolic link. I am able to use `exec -a` in bash to run
`python3` with `argv[0]` set to the wrapper script. This allows it to function
similarly to the
Michael Ferguson added the comment:
In the above I meant to include the `bin` path in the examples, but it does not
matter for the behavior
(exec -a test-venv/bin/python3 python3 -c 'import sys; print(sys.executable);
print (sys.p
Michael Ferguson added the comment:
> I'm not sure I understand exactly what you are trying to accomplish but one
> potential issue strikes me: you may need to ensure you are execing the right
> python binary by including a more complete path:
That does not help with the orig
Michael Felt added the comment:
On a different server, different compiler (xlc-v13, mine is xlc-v11) it gets
past this point.
So, perhaps it is a compiler issue.
As the second system is missing many 64-bit libraries - still cannot build
64-bit Python-3.9.
Low priority - imho
Michael Ferguson added the comment:
> For example, when I run the test exec on my macOS system, it is clear that
> the python3 being invoked is not the venv one but a different python3
> altogether that shows up earlier on PATH.
In the test case I am interested in, PATH is not s
Michael Ferguson added the comment:
> The way sys.prefix is calculated on macOS ensures that the correct sys.prefix
> is calculated even if you copy the binary to a different location. That's
> functionality I don't want to drop.
I agree with you that it's
Michael Felt added the comment:
Added "using xlc" to description.
When I have a system that has 64-bit support for gcc - I'll verify that it
works, or does not work, for me using gcc.
--
title: BUILD: AIX-64-bit segmentation fault -> BUILD: AIX-64-bit segmentatio
Michael Felt added the comment:
I have been experimenting with different hardware and AIX versions.
When building on AIX 5.3 - and the oldest libraries - test_math passes.
When I run the test on POWER8, using either xlc or gcc test_math fails with
just one element of the test.
When I run
Michael Felt added the comment:
For now, I am going to suggest closing this - as a bug in the xlc-v11 compiler
- and not worth researching.
I am able to build the 3.9 distribution as well as the 3.10 master using the
xlC-v13-1.3.2 (Try and Buy) version.
Thanks for thinking together
Michael Felt added the comment:
There seems to be a lot of interaction of OS level and compiler used.
* Waiting for the next bot run to get a different compiler.
+++
AIX 6.1.6 and older libraries - no test errors reported
AIX 7.1.4 and newer libraries - when using the binary built on 6.1.6
Michael Felt added the comment:
Yes, just probing, the version of gcc is irrelevant.
What I do believe is important is that bot run 374, 375 and 376 passed - On AIX
7.1 TL4 SP8.
The failure starting with 377 is an undefined variable.
"./Modules/posixmodule.c", line 15146.53: 1
Michael Felt added the comment:
This is still broken.
Since this was included in master - the AIX buildbot is failing to compile
(https://buildbot.python.org/all/#/builders/438/builds/391 and
https://buildbot.python.org/all/#/builders/302/builds/377)
Strangely enough - the first bot
Michael Foord added the comment:
Why not create a simple TestCase factory in load_tests?
Before a patch can be produced a clean api that offers a clear benefit over the
TestCase factory needs to be proposed.
--
___
Python tracker
<h
New submission from Michael Hipp :
A local *unexecuted* import appears to be changing the namespace. Attached
files are ready to run.
# over.py
SOMETHING = "overridden"
# main.py
OVERRIDE = False
SOMETHING = "original"
def main():
#global SOMETHING # uncomment
Michael Hipp added the comment:
Add'l over.py file
--
Added file: http://bugs.python.org/file24279/over.py
___
Python tracker
<http://bugs.python.org/is
Michael Hipp added the comment:
Even an *unexecuted* import assignment statement?
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Michael Foord added the comment:
hippmr: the problem is that by importing SOMETHING inside that function you're
creating a *local variable* called SOMETHING. If the override isn't executed,
and SOMETHING isn't global, then that local variable doesn't exist - which is
wh
Michael Goderbauer added the comment:
Here is the regenerated patch.
To write a test case I would need a PF_SYSTEM socket to connect to. As far as I
know Mac OS X doesn't provide a demo socket for this.
--
Added file: http://bugs.python.org/file24410/patch2.
Michael Foord added the comment:
This is a duplicate of issue 7559. See the discussion there.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Michael Mulich added the comment:
Sure does. But that's the point of the package.
Why is this super usage without arguments considered a hack?
>
> ___
> Python tracker
> <http://bugs.p
Michael Foord added the comment:
It's nicer for introspection if __self__ is None on builtin functions. But
fixing the docs is easier (and more backwards compatible).
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/is
Michael Foord added the comment:
assertEqual uses Python equality semantics - so if a str instance and a unicode
instance compare equal then assertEqual passes. This is by design.
The type check in assertEqual, that delegates to the different comparison
methods, is strict because we can&#
Michael Foord added the comment:
FWIW I think nose2 is going to have "test load time" parameterized tests rather
than "run time" parameterized tests, which is what I think we should do for
unit test. The API should be as simple as possible for basic cases, but
suitable fo
Michael Foord added the comment:
Note that apple have made gcc available, as part of command line tools for
XCode, freely (free developer registration required though) from:
https://developer.apple.com/downloads/
See:
http://kennethreitz.com/xcode-gcc-and-homebrew.html
Michael.Elsdörfer added the comment:
This should absolutely be implemented as **:
- It is pretty much standard. Recursive globbing is not supported everywhere,
but when it is, ** is used.
- A separate function will not allow me to let the *user* to decide when
recursion should be used. I fin
Michael Foord added the comment:
Yes, it would definitely be useful (as would a count of how far through the
test run we are [27/129] style). Getting to completing (even for testing) the
"extensible" unittest is something I will still do (and nose2 is being built
off the prototype
Michael Foord added the comment:
mock is being added to Python 3.3 as unittest.mock - so a helper TestCase.patch
should delegate to unittest.mock.patch.
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from Michael Foord :
Somewhere in the failure message for tests Guido would like to see the fully
qualified test name, suitable for copying and pasting into a test runner
invocation for running just that test.
--
assignee: michael.foord
components: Library (Lib
Michael Foord added the comment:
This would be nice (more powerful) as a general test method exclusion filter:
so run test discovery or fetch the specified test module / class and then
exclude individual tests that match the pattern.
We're looking to add a general test include filter,
New submission from Michael Foord :
"python -m unittest ..." is a pain to type. A "pyunit" script would be a nice
shorthand. (unittest2 has a unit2 script that does this.)
--
assignee: michael.foord
components: Library (Lib)
messages: 155476
nosy: michael.fo
Michael Foord added the comment:
Right "unit2" on its own does discover by default now. (On head, not sure if
that's released yet.)
--
___
Python tracker
<http://bugs.pyt
Michael Foord added the comment:
Fixed in 2.7. Worth fixing in Python 3.2 / 3.2 anyway as sourceless
distributions (bytecode only) are still possible.
--
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue10
Michael Foord added the comment:
Now fixed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Michael Foord :
PEP 417: Including mock in the Standard Library
http://www.python.org/dev/peps/pep-0417/
Tasks:
* Add mock with tests
* Cleanup mock code to remove Python 2 compatibility
* Add documentation
I'll close this issue when all the tasks are com
Michael Foord added the comment:
I'm working on a modified version of the patch that is switched on with a
command line option --timer=0.1 (or similar). Only tests that take longer than
the threshold have the time printed. --timer=0 is valid, but it still only
works when unittest is ru
Michael Foord added the comment:
Feel free to suggest changes on this issue.
_callable can probably go now I agree.
cls is only suggested by PEP 8 for classmethods I believe, and off the top of
my head I don't think mock has any of
Michael Foord added the comment:
Interesting. As I have to keep the external version of mock in sync with
unittest.mock, and I have more important things to do first (like the docs) it
would be a gratuitous change for no benefit.
If you have any more substantive suggestions for code cleanup
Michael Foord added the comment:
Thanks vinay (and ned). I thought that was the cause of the problem - but glad
you diagnosed and fixed it before I had to look into it. Patch looks good to
apply.
--
___
Python tracker
<http://bugs.python.
Michael Foord added the comment:
The code is *already* triggering execution through the use of hasattr. It could
be switched to use getattr_static instead, but the try...except in the patch
looks reasonable whether or not that change is made
Michael Foord added the comment:
So PyGame __init__.py has various not-a-module objects with __getattr__ that
raises a NotImplementedError on every attribute access. Changing inspect to use
getattr_static, so it doesn't trigger code execution on attribute access, would
fix the pr
Michael Foord added the comment:
Yes there was a discussion on python-dev. Various people spoke in favour,
no-one against:
http://mail.python.org/pipermail/python-dev/2012-March/117566.html
--
___
Python tracker
<http://bugs.python.org/issue14
Michael Foord added the comment:
The opposite of calling assertRaises is simply calling the code. A comment as
to why you're calling the code is sufficient documentation as to the intent of
the test.
In general the difference be a test failure and error is not useful - you
*still* ha
Michael Foord added the comment:
Thanks for doing the work Matt. In principle the patch looks good, and being
able to run standard library tests direct from unittest is nice. It's also a
step towards being able to use test discovery to run standard library tests.
Is the thread setu
Changes by Michael Foord :
--
title: Support the test_cases protocol in the stdlib tests -> Support the
load_tests protocol in the stdlib tests
___
Python tracker
<http://bugs.python.org/issu
Michael Foord added the comment:
If we do create a proxy module I'd like to suggest adding all or part of
Phillip Eby's ProxyTypes:
http://pypi.python.org/pypi/ProxyTypes
I haven't used it directly, but did read through it a while ago and have ended
up re-implementing chun
Michael Foord added the comment:
Yes, it would be preferable if unittest could load the set of test classes for
each of these test modules without *requiring* a load_tests function.
Each test module will need looking at to see if the standard set of test
classes exported by the module is the
Michael Foord added the comment:
Test discovery is only needed for finding tests in directories of tests - for a
single test module the standard test loader should work fine.
--
___
Python tracker
<http://bugs.python.org/issue14
Michael Foord added the comment:
One way to exclude base classes from being loaded as tests is to have the base
class *not* inherit from TestCase (just from object) - and use it as a mixin
class for the actual TestCases.
This isn't particularly elegant (but works fine). A better w
Michael Foord added the comment:
Yes, feel free to create an issue for that. If you provide a patch for it (with
tests) I'll review it.
The decorator itself can be applied to both TestCase and FunctionTestCase in
unittest as well. One implementation would be to apply a private attribu
Michael Foord added the comment:
Because you then have classes that inherit from object calling methods that
clearly don't exist (until you subclass them *and* TestCase). It looks weird
and also means the classes can't be tested in isolation.
With a class decorator the code w
Michael Foord added the comment:
It still looks weird to see code calling methods that obviously don't exist,
and with no indication *at the call site* where they come from. Making it
clearer with naming would help: "TestThingMixin" or similar.
There are classes like this
Michael Foord added the comment:
Besides which, the mixin pattern won't *stop* working if we provide this extra
functionality - it would just be an alternative for those (like myself) who
think it impedes code readability. :-)
At this point we're off topic for the *specific issue
Michael Foord added the comment:
Looks good to me. Note that if module level setup and teardown is needed for
running tests then it should be possible to do this with setUpModule and
tearDownModule functions (unless those should *only* be done when running under
regrtest
Michael Foord added the comment:
So the technique I suggested is that the TestLoader checks classes for the
"testbase" (or whatever we call it) *in the class dict*. So inheritance doesn't
matter - a class is only excluded from test loading if it has the attr
Michael Foord added the comment:
Here are my objections to the standard (but not widely used outside our own
tests) mixin pattern for base testcases (copied and pasted from issue 14408):
Because you then have classes that inherit from object calling methods that
clearly don't exist (
Michael Foord added the comment:
So the logic of the "pattern" argument to "load_tests" is that it should not be
None when test discovery is loading the __init__.py module of a test package.
However, because most patterns will actually *prevent* __init__.py from b
Michael Foord added the comment:
Also the patch to allow the pattern to be None (and revert to the default
pattern in this case) looks good.
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from Michael Foord :
Pickling uses __class__ instead of type(obj) to determine the type to pickle.
This means that objects which pretend to be other objects (like proxy and mock
objects) can't be pickled correctly:
>>> class Foo(object):
... __class__ = property(
Michael Foord added the comment:
So, changing copyreg.py to use type(self) instead of self.__class__ isn't
sufficient. _pickle accesses __class__ as well it seems. However I'm running
all tests with this change in place to see if it breaks intended behaviour:
Python 3.3.0a1
Michael Foord added the comment:
test_pickle still passes with only copyreg.py modified.
With one additional change in pickle.py (line 405 to use type(obj) instead of
obj.__class__) the pickling works as I would hope (I would need assistance to
fix _pickle):
>>> import sys
[6
Changes by Michael Foord :
--
resolution: -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Michael Foord added the comment:
Nick - in general proxy objects have a *reference* to their target (weakref
being somewhat of a special case), and pickle can already handle multiple
references to the same target when deserializing an object graph. So I don't
see that argument holding
Michael Felt added the comment:
I am not an OpenSSL expert - and I am conscious of OpenSSL changes with regard
to 'acceptance' of anything self-signed.
And, what it looks like you are trying to do with an updated 'signing" .pem is
to remove the 'self-signed'
Michael Felt added the comment:
p.s. On Centos I could not even get a python3 (at least not easily).
On debian (on POWER) I get the same error (message) as on AIX - although the
line number did change.
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed
Michael Felt added the comment:
I believe (or hope) this is related to issue35828.
This is, as far as I can tell, a compiler issue.
It appears "always" in the bot situation (not building as root) when using
xlc-v11, but not when using gcc-4.7.4.
So, when the test failure "
Michael Felt added the comment:
Again - how can I get the core (dump) mentioned in the error message. When I
force this situation I have several core dumps - not "the one".
--
___
Python tracker
<https://bugs.python.o
New submission from Michael Felt :
On AIX, with commit 4fb15021890d327023aefd95f5a84ac33b037d19 (HEAD -> master,
origin/master, origin/HEAD)
test_thread is failing.
The three sub_tests that exit as ERROR are:
ERROR: test_threads_join_2 (test.test_threading.SubinterpThreadingTests)
ER
New submission from Michael Felt :
==
test_create_connection_ipv6_scope
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
--
Traceback (most
Michael Felt added the comment:
On 21/05/2019 12:08, Michael Felt wrote:
> Michael Felt added the comment:
>
> p.s. On Centos I could not even get a python3 (at least not easily).
>
> On debian (on POWER) I get the same error (message) as on AIX - although the
> line
Change by Michael Sullivan :
--
pull_requests: +13391
___
Python tracker
<https://bugs.python.org/issue36878>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
Repeating a bot of what I added to PR13463
AIX has native support for thread-id since at least AIX 4.1 (1994-1995) where
every process has an initial TID (PID are even numbers and "own" the resources,
TID are odd and are the "workers&quo
Michael Felt added the comment:
from below:
In case of 3.7 first call to _ensure_resolved returns
('fe80::1', 12345, 0, 1)
then second call returns
('fe80::1', 12345, 0, 0)
Notice that scope is now completely lost and is set to 0, thus actual call to
socket.connect is w
1101 - 1200 of 3024 matches
Mail list logo
