[Python-Dev] PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Is there a bestiary of examples for the current pattern matching proposal(s)? It seems I don't have a good handle on how one matches simple tests like callability, function signatures, possession of specific attribute(s).etc. Also will matching ever extend into the Typing universe? -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OKBOTKDQ6WBEDPCBTDRYRI5HRDHRDVER/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
.. Also will matching ever extend into the Typing universe? In what way do you have in mind? With protocol support baked into PEP 634 that already ties into type hints. -Brett . thanks for the answers; the only one missing is whether there is an actual bestiary of examples, but I guess the PEPs will have to do for now. It's unlikely I will need any of this for a while so examples will appear over time. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6JNN4AEI6DJYNUQM7MJADZDII7KXEJPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] seg fault in 3.10a4
Not sure if this is where I should report, but I have a segfault in reportlab userguide creation with 3.10a4. I am getting this info from coredumpctl running archlinux with Linux hostname 5.10.6-arch1-1 #1 SMP PREEMPT Sat, 09 Jan 2021 18:22:35 + x86_64 GNU/Linux the error is Message: Process 1530711 (python) of user 1000 dumped core. Stack trace of thread 1530711: #0 0x7f7c9bf72615 raise (libc.so.6 + 0x3d615) #1 0x7f7c9bf5b862 abort (libc.so.6 + 0x26862) #2 0x7f7c9bfb45e8 __libc_message (libc.so.6 + 0x7f5e8) #3 0x7f7c9bfbc27a malloc_printerr (libc.so.6 + 0x8727a) #4 0x7f7c9bfbd64c _int_free (libc.so.6 + 0x8864c) #5 0x5631260a01dd n/a (/home/robin/devel/reportlab/.py310/bin/python310 + 0x1401dd) 1) I compile this from source using the standard LTO method my script looks like ### CFLAGS="-march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fno-semantic-interposition" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -rpath=$HOME/LOCAL/3.10.0a4/lib -fno-semantic-interposition" ./configure \ --prefix=$HOME/LOCAL/3.10.0a4 \ --with-computed-gotos \ --enable-optimizations \ --with-lto \ --enable-ipv6 \ --with-system-expat \ --with-dbmliborder=gdbm:ndbm \ --with-system-ffi \ --with-system-libmpdec \ --enable-loadable-sqlite-extensions && make EXTRA_CFLAGS="$CFLAGS" && make install ### 1) can I get more information using a different compile setup 2) or can I get more information with the python run. I just used $ python genuserguide.py Built story contains 1843 flowables... Saved "/home/robin/devel/reportlab/REPOS/reportlab/docs/reportlab-userguide.pdf" free(): invalid pointer Aborted (core dumped) 3) I am running in an old style virtual environment generated using a modified virtualenv 16.2.0 (to fix wrong usage of sys.version[:3] in path names) 4) All other tests seem fine including tests of image generation and the accelerated strinGWidths etc etc so I am a bit mystified. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5DCR2R6POCOHTPFUOY4F5G7GTBYX6OPO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: seg fault in 3.10a4
On 17/01/2021 13:49, Terry Reedy wrote: On 1/17/2021 8:05 AM, Stestagg wrote: Hi Robin It would be ideal if you could please create a new issue here: https://bugs.python.org/ <https://bugs.python.org/> If 'reportlab userguide creation' uses any 3rd party compiled C code, this may be premature. bugs.python.org is for patching cpython. Seg faults with 3rd party extensions are often, even usually due to a bug in the extension that we cannot fix, or for new python version, a missing upgrade. The questions Robin asked seem like a reasonable start. He might get additional suggestions from python-list from someone who has seen something similar. Thanks, we have two C extensions & pillow so I will do as you suggest and ask in the python list for debugging advice. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4R72YLNH2LFNCOOEXQAF3Q2MBHEKMAPU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: seg fault in 3.10a4
On 17/01/2021 16:54, Victor Stinner wrote: See https://github.com/python-pillow/Pillow/issues/5193 and https://github.com/python-pillow/Pillow/pull/5194 for a Pillow crash on Python 3.10. A fix is merged in master, but there is no release containing the fix yet. https://github.com/python-pillow/Pillow/commit/543fa2ceb78103c7ae098900c315748a9283e4d4 Victor Thanks for that. I might try to build pillow from git and see if that helps. ...-- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JMQ25DF4OW7JRMU5Y6D6UDFXOCTDIRFB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1
On 04/06/2021 19:29, Steve Dower wrote:
...
While we were investigating the reliably broken behaviour, we figured that related behaviour was
*unreliably* broken on all platforms.
Specifically, if you imported a module through a relative path (resolved to CWD), changed the CWD, cleared the module
cache, and reimported, you would still get the original module, contrary to the intent of getting the newly resolved
module. ("Correct" code would have also cleared the import path caches, not just sys.modules.) This was because the
module info was cached using the relative path, and so would be used later even though its absolute path had changed.
Someone reported this change in 3.8 and we decided to revert it in existing released, because the bugfix was for an
obscure enough situation that it really wasn't worth breaking any existing versions. For unreleased versions, it's
better to fix it so that imports will be more reliable in the future.
Unfortunately we are using these relative imports to implement plugins for an xml language processor so this is likely
not just an accident of ordering the failing tests. I agree we have to get a plugin module a bit more directly using the
import internals. I still think we might need to control sys.path as presumably the plugin code could have imports of
parallel modules.
I'm beginning to understand that messing about with sys.path/modules/meta_path
etc etc is a lot harder than it used to be.
Incidentally I find that I am able to import a namespace module directly; this
code doesn't crash (at least in python >= 3.6
###
#timpA.py don't run with any meaningful directory A
import importlib
def main():
module = importlib.import_module('A')
print('module=%r' % module)
if __name__=='__main__':
main()
###
in python 3.6-3.9 this prints out "module=" in 3.10.0b1
it prints
"module=)>".
I thought I had to use pkgutils or pkg_resources to mess with these new-fangled
packages.
Likewise I find that the python statement 'import A' also doesn't fail and A is
a namespace. I feel quite stupid now :(
--
Robin Becker
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/KMJAQUGSXINVBLQOMREURUFN4LVCEIVX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1
I have a failing test case in 3.10.0b1 for code that uses changes to sys.path and attempts to load unpackaged modules by
changing directory and placing '.' into sys.path; the code works as expected in 2.7.18, 3.6-3.10.0a7.
I printed out related variables in the a7 and b1 runs and find that sys.path is identical (modulo version name changes)
and that os.getcwd() is as expected and that os.path.isfile('./%s.py' % modulename) is True.
In a7 exec('%s as m', NS) works, but in b1 I get ModuleNotFoundError.
I can fix the problem by changing
sys.path.insert(0,'.')
into
sys.path.insert(0,os.getcwd())
The behaviour of '.' in sys.path has always been slightly mysterious, but is this a real bug and have we just been lucky
for 20 years?
I have placed some details here
https://www.reportlab.com/ftp/import-bug-310b1.txt
ReportLab has quite a large codebase and I think it would be hard to get a concise test of this behaviour change. I
would be glad if this is an expected change a7-->b1 and if the use of '.' in this way has become somehow wrong.
I do know that during the tests the errant code is executed with different values for the target directory; the first
usage seems to succeed.
--
Robin Becker
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DE3MDGB2JGOJ3X4NWEGJS26BK6PJUPKW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1
On 03/06/2021 18:14, Senthil Kumaran wrote:
On Thu, Jun 03, 2021 at 09:55:57AM -0700, Guido van Rossum wrote:
Maybe this?
04732ca993 bpo-43105: Importlib now resolves relative paths when creating
module spec objects from file locations (GH-25121)
Likely!. But
https://github.com/python/cpython/commit/04732ca993fa077a8b9640cc77fb2f152339585a
was supposed to a platform specific bug fix.
I didn't a sense that reportlab regression detected was platform
specific one. The behavior change is an interesting one though.
The regression may well be a platform issue. I am by no means an expert at building python; I followed a recipe from the
ARCH PKGBUILD of some time past so perhaps there are problems from my incompetence.
More interesting thing for me was developers running large test suites
between alpha and beta releases, and reporting bugs! :-)
You guys can certainly develop language changes faster than us maintainers can use them; the dead hand of past usage is
a real handicap.
I have managed a smaller example which breaks for me in arch linux latest.
The self contained code is here
https://www.reportlab.com/ftp/timport-310b1.py
I switched to using importlib.import_module as I think that can now always be
used in the versions we support.
To generate a test base I used an empty directory and then run (in bash)
for d in A B;do rm -rf $d; mkdir $d;echo "print('+ in module %s' % __name__)" > $d/$(echo $d | tr [:upper:]
[:lower:]).py; done
or
$ for d in A B;do
>rm -rf $d
>mkdir $d
>echo "print('+ in module %s' % __name__)" \
> > $d/$(echo $d | tr [:upper:] [:lower:]).py
> done
to create two simple modules in dirs A & B.
If I run python timport-310b1.py in 3.10.0a7 I occasionally see a problem, but in 3.10.0b1 or b2 I see the problem every
time; the TB ends like this
print(recursiveImport(mn, debug=1))
File "/home/robin/devel/reportlab/REPOS/timpbug/tests/timport-310b1.py", line
36, in recursiveImport
return importlib.import_module(modulename)
File
"/home/robin/devel/reportlab/.py310/lib/python3.10/importlib/__init__.py", line
126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'a'
The occasional problem with 3.10.0a7 make me think some random element is at
work perhaps hashing stuff.
--
Robin Becker
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UJKVOAR6BUDOIFRSUGQ3THFA2DYG47PQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 18/10/2021 18:50, Senthil Kumaran wrote: Your configure script did pick up openssl as the support version was not found. What is your operating system? Make sure you have supported version of ssl. Python requires openssl 1.1.1 or higher. ... I tried to build this on ubuntu 18.04, but got the _ssl problem; it definitely has openssl 1.1.1 installed. On updated Arch linux no issue. during configure I see that compiling and linking against openssl works. with the simplest ./configure --prefix=$HOME/LOCAL/3.10.0 I find _ssl is not importable (_socket is). If I try setting --with-openssl-rpath I get _ssl importable, but it fails because _socket is not importable. It's not a big deal as I can install python 3.10.0 using deadsnakes-ubuntu-ppa-bionic ppa. I think the problem here is that I don't seem to have a single openssl root /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/include/openssl/ This all used to work in Python 3.9.x, but I suppose some improvement(s) have been made. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MWMMTAE734FGARKPERO732YYRHUJ6BOE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 19/10/2021 11:21, Christian Heimes wrote: On 19/10/2021 11.57, Robin Becker wrote: .. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions. They have been tested on Debian-like and Fedora-like platforms: https://docs.python.org/3/using/unix.html?highlight=openssl#custom-openssl Unfortunately I don't have a custom openssl installation although it may not appear/behave as the python configuration wants. I am using the officially approved installed version of openssl so far as I know. I'm aware that Ubuntu 18.04 is now somewhat out of date, but I would expect a simple configure & make dance to succeed. I'm working with linux for dummies(self) and need to install/update/upgrade openssl, libssl-dev. After that _ssl _hashlib are compiled and importable. I suppose the configure 'compiling with openssl' test is a bit naive. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PIYZS5WFZ4RRATOGSLSSMOS2LR47LKTB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: compiled python3.10 is unable to find _ssl
On 19/10/2021 16:45, Christian Heimes wrote: We use the standard AX_CHECK_OPENSSL() m4 macro from autoconf-archive to detect OpenSSL. The macro uses pkg-config to detect OpenSSL. It doesn't check for specific version, though. We don't want to prevent people with outdated OpenSSL or LibreSSL from building Python without ssl support. Christian I would not suggest that, but if the test at the end of the configure had said it can compile against openssl, but that a wrong or insufficient information would prevent building _ssl then a lot of cycles could be saved. I suppose that might be impossible as the test might need to actually try and build _ssl.so. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EOQEXMWZFD32BXRHQZ32ULI4NYFTLFJN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] is __self__ an implementation detail
A gentoo developer reported a symlink loop problem in reportlab's setup.py where we search for specific headers. The 'fixed' function looks like this def findFile(root, wanted, followlinks=True): visited = set() for p, D, F in os.walk(root,followlinks=followlinks): #scan directories to check for prior visits #use dev/inode to make unique key SD = [].append for d in D: dk = os.stat(pjoin(p,d)) dk = dk.st_dev, dk.st_ino if dk not in visited: visited.add(dk) SD(d) D[:] = SD.__self__ #set the dirs to be scanned for fn in F: if fn==wanted: return abspath(pjoin(p,fn)) the fix is reported to have worked, but the developer is querying the lifting of SD.append using the construct SD = [].append loop involving appends to the list . D[:] = SD.__self__ his objection was that using __self__ might be implementation sensitive. I cannot tell from the documentation (eg https://docs.python.org/3.10/reference/datamodel.html) if these magic methods are part of python or of the implementation. On the other hand as a longtime python programmer I wonder if such simple cases are already optimized out in the produced bytecode; for years I have been avoiding s += 'string' and only recently found out that it was handled as a special case. -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3TAF3LR35HRRE6LD7XQ7O4BXPNLVXFVX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] The second Python 3.11 beta (3.11.0b2) is available
On 01/06/2022 16:58, Pablo Galindo Salgado wrote: Update: we have decided to release Python 3.11.0b3. Let's hope this one is free of the curse :) Hi I hade a couple of failures related to the compile failure for ASTs with wrongly ranged start-end attributes. After spending a while sorting those I hope that b3 will still work for those case. Will the reasonable range requirement eventually be made mandatory? It does seem like a good idea. Will there be an extra beta? -- Robin Becker ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6VCXNJWBJRULQXPJRUP2VC7DPR2UCMY5/ Code of Conduct: http://python.org/psf/codeofconduct/
