[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/
[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: 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] 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 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: 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] 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] 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: 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: 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] 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: 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] 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 622 version 2 (Structural Pattern Matching)
If we are still not certain about the exact language to describe match then I would ask if the 'case' token is really required. It seems that I would prefer match expr: pattern0: block0 pattern1: block1 . else: blockdefault where the else: clause is optional. Also for me the unusual case is the assignment to names in the pattern and I would prefer that that be marked in some way; I didn't like .name, but ?name seems OK (or perhaps => name). Also the restriction that assigned vars should only occur once in a pattern seems wrong. I would regard it as an additional constraint on the match, but I do admit I don't fully understand what's allowed in patterns. Please disregard if the above is totally stupid. ___ 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/5SJY2HAT2CHG2BKYV4IZDZVM2BZILXTT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing
Sorry for noise, but obviously most of my pasted text went wrong; not sure how to use this modern mailman. I see a syntax error in 3.9a6 with the code norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') ___ 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/JXRGQW4MYZ7ACA4TRHGNXFOFKVJTENEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing
While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using the standard configure make dance. Is this a real change? robin@minikat:~/devel/reportlab/REPOS/reportlab/tests $ python Python 3.8.2 (default, Apr 8 2020, 14:31:25) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') >>> robin@minikat:~/devel/reportlab/REPOS/reportlab/tests $ python39 Python 3.9.0a6 (default, Apr 29 2020, 07:46:29) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') File "", line 1 norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') ^ SyntaxError: invalid string prefix >>> robin@minikat:~/devel/reportlab/REPOS/reportlab/tests $ python39 -X oldparser Python 3.9.0a6 (default, Apr 29 2020, 07:46:29) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') File "", line 1 norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') ^ SyntaxError: invalid string prefix >>> robin@minikat:~/devel/reportlab/REPOS/reportlab/tests ___ 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/PCQD2REYQ7GT6GVY2FLYEASVKRS756HO/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Backport PEP 3129: Class Decorators
Christian Heimes schrieb: PEP 3107 (function annotation), PEP 3104 (nonlocal) and PEP 3132 (extended iterable unpacking: a, *b = 1,2,3) are IMHO other useful feature for 2.6. nonlocal would require a __future__ import. I'm planning to work on PEP 3107 (function annotations) after I have finished backporting PEP 3102 (keyword-only arguments) (issue1745). Could someone with access rights update the spreadsheet so there won't be duplicated efforts? http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGggid=2 Robin Stocker ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Fair enough. Robin On 30/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Robin Bryce schrieb: Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this contract in spirit is broken by vendor repackaging they should: * Call the binaries something else because it is NOT python any more. * Setup the installation layout so that it does NOT conflict or overlap with the standard layout. * Call the whole package something else. I think that would be counter-productive. If applied in a strict sense, you couldn't call it Python anymore if it isn't in /usr/local. I see no point to that. It shouldn't be called Python anymore if it doesn't implement the Python language specification. No vendor is modifying it in such a way that print Hello stops working. Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ? I'm not sure in what applications that would be useful. I would strongly prefer _not_ write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate This is not a standard python runtime to the python run time, early failure (in the application) with informative error messages becomes much more viable. Again: none of the vendors modifies Python in a way that what you get is not a standard Python runtime. They *all* are standard Python runtimes. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 28/11/06, Martin v. Löwis [EMAIL PROTECTED] wrote: I personally agree that Linux standards should specify a standard layout for a Python installation, and that it should be the one that make install generates (perhaps after make install is adjusted). Whether or not it is the *LSB* that needs to specify that, I don't know, because the LSB does not specify a file system layout. Instead, it incorporates the FHS - which might be the right place to define the layout of a Python installation. For the LSB, it's more import that import httplib gives you something working, no matter where httplib.py comes from (or whether it comes from httplib.py at all). Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this contract in spirit is broken by vendor repackaging they should: * Call the binaries something else because it is NOT python any more. * Setup the installation layout so that it does NOT conflict or overlap with the standard layout. * Call the whole package something else. But I can't see that happening. Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ? I would strongly prefer _not_ write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate This is not a standard python runtime to the python run time, early failure (in the application) with informative error messages becomes much more viable. Eg sys.vendor_variant would be orthogonal to sys.version and sys.version_info Given: python -c import sys; print sys.version GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) A regex on sys.version does not seem like a good way to get positive confirmation I'm using the Canonical variant (pun intended) python -c from distutils.util import get_platform; print get_platform() Tells me nothing about the vendor of my linux distribution. Except, ironically, when it says ImportError Cheers, Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Actually, I meant that (among other things) it should be clarified that it's alright to e.g. put .pyc and data files inside Python library directories, and NOT okay to split them up. Phillip, Just to be clear: I understand you are not in favour of re-packaging data from python projects (projects in the distutils sense), separately and I strongly agree with this view. Are you opposed to developers choosing to *not* bundle data as python package data ? How much, if any, of the setuptools / distutils conventions do you think could sensibly peculate up to the LSB ? There are a couple of cases in ubuntu/debian (as of 6.10 edgy) that I think are worth considering: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Is it unreasonable for a particular vendor to decide that, on their platform, the will disable Python's packaging conventions ? Is there any way to keep the peace on this one ? Cheers, Robin On 27/11/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby napsal(a): Just a suggestion, but one issue that I think needs addressing is the FHS language that leads some Linux distros to believe that they should change Python's normal installation layout (sometimes in bizarre ways) (...) Other vendors apparently also patch Python in various ways to support their FHS-based theories of how Python should install files. +1 on that. There should be a clear (and clearly presented) idea of how Python is supposed to be laid out in the distribution-provided /usr hierarchy. And it would be nice if this idea complied to FHS. It would also be nice if somebody finally admitted the existence of /usr/lib64 and made Python aware of it ;e) Actually, I meant that (among other things) it should be clarified that it's alright to e.g. put .pyc and data files inside Python library directories, and NOT okay to split them up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/robinbryce%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post)
This has an sf number now #1537167, and hopefully a clearer
explanation of what I think the problem is. This is not a duplicate of
the earlier PEP 302 Fix thread.
Thanks,
Robin
On 07/08/06, Robin Bryce [EMAIL PROTECTED] wrote:
Hi,
Appologies for the lack of an sf#. I tried to submit this there but
couldn't. (sf is logging me out each time I visit a new page and it is
refusing my attempt to post anonymously).
Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
The need for speed patch commited in revision r46372 included a change
whose intent was to reduce the number of open calls. The `continue`
statement at line 1283 in import.c:r51136 has the effect of skipping
the builtin import machinery if the find_module method of a custom
importer returns None.
In Python 2.4.3, if find_module returned None the builtin machinery is
allowed to process the path tail.
In my particular case I am working on an importer that deals with kid
templates that may or may not exist as .py[c] files.
The short of it is that in Python 2.4.3 this produces a usable module
``__import__('foo.a/templateuri')`` wheras in 2.5b3 I get import
error. The python 2.4.3 implementation *allows* module paths that are
not seperated with '.' Python 2.5b3 does not allow this and it does
not look like this was an intentional change. I believe this point
about 'illeagal' module paths is actualy independent of the regresion
I am asserting. Detailed session logs are attatched (following the sf
guidance even though I'm posting to py-dev)
The 'use case' for the importer is: Robin wants to package a default
template file as normal python module and provide a custom importer
that allows users of his package to reference both: there own
templates and html files on the file system in arbitrary locations AND
the stock templates provided as python modules under the same name
space. He would like to leave normal imports to the standard
machinery.
Cheers,
Robin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post)
Hi,
Appologies for the lack of an sf#. I tried to submit this there but
couldn't. (sf is logging me out each time I visit a new page and it is
refusing my attempt to post anonymously).
Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
The need for speed patch commited in revision r46372 included a change
whose intent was to reduce the number of open calls. The `continue`
statement at line 1283 in import.c:r51136 has the effect of skipping
the builtin import machinery if the find_module method of a custom
importer returns None.
In Python 2.4.3, if find_module returned None the builtin machinery is
allowed to process the path tail.
In my particular case I am working on an importer that deals with kid
templates that may or may not exist as .py[c] files.
The short of it is that in Python 2.4.3 this produces a usable module
``__import__('foo.a/templateuri')`` wheras in 2.5b3 I get import
error. The python 2.4.3 implementation *allows* module paths that are
not seperated with '.' Python 2.5b3 does not allow this and it does
not look like this was an intentional change. I believe this point
about 'illeagal' module paths is actualy independent of the regresion
I am asserting. Detailed session logs are attatched (following the sf
guidance even though I'm posting to py-dev)
The 'use case' for the importer is: Robin wants to package a default
template file as normal python module and provide a custom importer
that allows users of his package to reference both: there own
templates and html files on the file system in arbitrary locations AND
the stock templates provided as python modules under the same name
space. He would like to leave normal imports to the standard
machinery.
Cheers,
Robin
bugreport.rst
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
outbound x = 1 x = 2 evaluating using Jeremy Hilton's' list: 1. is a real word 2. For me - in python - it would mean: Is found in 'outer' scope and is already bound. And the literal meaning of 'outbound 'headed away' [1] is pretty darn close to what I mean when I spell the usual mutables kluge. 3 statement is positive form 4. I like it could not find a use of outbound in python source (2.4.3) [1] http://dictionary.reference.com/search?q=outbound Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
PEP 3103, When to Freeze the Dispatch Dict/Option 1 2 things resonated with me for Raymond's proposal and the follow up: - It seemed agnostic to almost all of the independently contentious issues. - is defined tightly enough to allow room for growth and elaboration over time [Raymond]. In particular it left room for const/static/only/cached/etc to come along later. I think its worth acknowledging this in the PEP. Is nothing better than something in this case ? I don't know. I think we need a PEP for const/static/only/cached/precomputed or whatever people like to call it. Once we have (say) static, I think making the case expressions static by default would still cover all useful cases, and would allow us to diagnose duplicate cases reliably (which the if/elif chain semantics don't allow IIUC). If the expectation is that static/const will evolve as a sibling pep, does this not make Raymond's suggestion any more appealing, even a little ? Is it unacceptable - or impractical - to break the addition of switch to python in two (minor version separated) steps ? Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
But what's the point? We have until Python 3000 anyway. Ah, my mistake. In my enthusiasm, I foolishly got the time frames of peps 3103 275 mixed up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: Robin Munn wrote: Revision 4077 is fine now. However, the same problem exists in revision 4284, which has a 0x01 character before the word add. Same solution: I now have fixed that as well. Regards, Martin And my script just finished running, with no further errors of this type found. So doing an SVK mirror of the repository should work now, barring any further surprises. I'm starting the SVK sync now; we'll see what happens. Thanks for fixing these! - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDacVN6OLMk9ZJcBQRApUbAJ9+Ly5vPr8HRmoRbwJ3po4IWe8PBwCePTdm XNx8HGqPvs7fwahHuJSogMw= =a6Nc -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] No more problems with new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin Munn wrote: So doing an SVK mirror of the repository should work now, barring any further surprises. I'm starting the SVK sync now; we'll see what happens. Confirmed; the SVK mirror took about 18 hours, but it completed successfully with no further problems. Again, thanks for fixing the issues so quickly. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaqiZ6OLMk9ZJcBQRAjGuAJwLmbrxBgrHYUb/7LOvjq89GfKrWACghGgn pvuMT5edAfMw3OAoZf5mJiw= =2i88 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to mirror the brand-new Python SVN repository with SVK, to better be able to track both the trunk and the various branches. Since I'm not a Python developer and don't have svn+ssh access, I'm doing so over http. The process fails when trying to fetch revision 4077, with the following error message: RA layer request failed: REPORT request failed on 'projects/!svn/bc/41373/python': The REPORT request returned invalid XML in the response: XML parse error at line 7: not well-formed (invalid token) (/projects/!svn/bc/41373/python) The thread at http://svn.haxx.se/dev/archive-2004-07/0793.shtml suggests that the problem may lie in the commit message for revision 4077: if it has a character in the 0x01-0x1f range (which are invalid XML), then Subversion methods like http: will fail to retrieve it, while methods like file: will succeed. I haven't tried svn+ssh: since I don't have an SSH key on the server. Trying svn log -r 4077 http://svn.python.org/projects/python/; also fails: subversion/libsvn_ra_dav/util.c:780: (apr_err=175002) svn: REPORT request failed on '/projects/!svn/bc/4077/python' subversion/libsvn_ra_dav/util.c:760: (apr_err=175002) svn: The REPORT request returned invalid XML in the response: XML parse error at line 7: not well-formed (invalid token) (/projects/!svn/bc/4077/python) When I visit http://svn.python.org/view/python/?rev=4077, I can see the offending log message. Sure enough, there's a 0x1b character in it, between the space after Added and the h immediately before the word Moved. This problem can be fixed by someone with root permissions on the SVN server logging in and running the following: echo New commit message goes here new-message.txt svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt If there are other, similar problems later in the SVN repository, I was unable to find them because the SVK mirror process consistently halts at revision 4077. If revision 4077 is fixed and I turn up other log problems, I'll report them as well. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaRd46OLMk9ZJcBQRApjAAJ9K3Y5z1q4TulqwVjmZTZb9ZgY31ACcD8RI fNFmGL2U4XaIKa2n6UUyxEA= =tEbq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: Robin Munn wrote: echo New commit message goes here new-message.txt svnadmin setlog --bypass-hooks -r 4077 /path/to/repos new-message.txt Thanks for pointing that out, and for giving those instructions. I now corrected the log message. Revision 4077 is fine now. However, the same problem exists in revision 4284, which has a 0x01 character before the word add. Same solution: echo New commit message goes here new-message.txt svnadmin setlog --bypass-hooks -r 4284 /path/to/repos new-message.txt If there are two errors of the same type within about 200 revisions, there may be more. I'm currently running svn log on every revision in the Python SVN repository to see if I find any more errors of this type, so that I don't have to hunt them down one-by-one by rerunning SVK. I'll post my findings when I'm done. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaUho6OLMk9ZJcBQRAg5eAJ9cJTPKX69DhXJyoT/cDV5GmZlC3QCfRj/E wCix8IYU8xbh5/Ibnpa+kg4= =+jLR -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with revision 4077 of new SVN repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin Munn wrote: Revision 4077 is fine now. However, the same problem exists in revision 4284, which has a 0x01 character before the word add. Same solution: echo New commit message goes here new-message.txt svnadmin setlog --bypass-hooks -r 4284 /path/to/repos new-message.txt If there are two errors of the same type within about 200 revisions, there may be more. I'm currently running svn log on every revision in the Python SVN repository to see if I find any more errors of this type, so that I don't have to hunt them down one-by-one by rerunning SVK. I'll post my findings when I'm done. My script is up to revision 17500 with no further problems found; I now believe that 4077 and 4284 were isolated cases. Once 4284 is fixed, it should now be possible to SVK-mirror the entire repository. - -- Robin Munn [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDaXJF6OLMk9ZJcBQRAtZpAJ9iE1SlRJiQQOdIuBFuvjmQG3gshACgl9/A vbsGD0bX3NCirQC5qtxdLYo= =sgk/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340 - possible new name for block-statement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: | How about, instead of trying to emphasize how different a | block-statement is from a for-loop, we emphasize their similarity? | | A regular old loop over a sequence or iterable is written as: | | for VAR in EXPR: | BLOCK | | A variation on this with somewhat different semantics swaps the keywords: | | in EXPR for VAR: | BLOCK | | If you don't need the variable, you can leave the for VAR part out: | | in EXPR: | BLOCK | | Too cute? :-) Far too close to the for loop, IMHO. I read that, I'd have to remind myself every time, now, which one is it that can receive values passed back in: for ... in, or in ... for? I'm definitely -1 on that one: too confusing. Another possibility just occurred to me. How about using? ~using EXPR as VAR: ~BLOCK Reads similarly to with, but leaves the with keyword open for possible use later. Since it seems traditional for one to introduce oneself upon first posting to python-dev, my name is Robin Munn. Yes, my name is just one letter different from Robin Dunn's. It's not like I *intended* to cause confusion... :-) Anyway, I was introduced to Python a few years ago, around version 2.1 or so, and fell in love with the fact that I could read my own code six months later and understand it. I try to help out where I can, but I don't know the guts of the interpreter, so on python-dev I mostly lurk. Robin Munn -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcbf16OLMk9ZJcBQRAuYpAJ4n24AgsX3SrW0g7jlWJM+HfzHXMwCfTbTq eJ2mLzg1uLZv09KDUemM+WU= =SXux -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
