Re: Circular Import
found a solution: importing modules instead of classes, ex. -- square.py import circle ... @classmethod def from_circle(cls, circle: circle.Circle) -> Square: ... return cls(...) -- https://mail.python.org/mailman/listinfo/python-list
Circular Import
How can I avoid circular imports keeping separated modules ? -- square.py from circle import Cirle class Square: def __init__(self): ... @classmethod def from_circle(cls, circle: Circle) -> Square: ... return cls(...) -- circle.py from square import Square class Circle: def __init__(self): ... @classmethod def from_square(cls, square: Square) -> Circle: ... return cls(...) -- https://mail.python.org/mailman/listinfo/python-list
[issue44445] Add `site-include` install scheme path in sysconfig
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue5> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43976] Allow Python distributors to add custom site install schemes
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue43976> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45413] Add install scheme for virtual environments
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue45413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
installazione numpy
l'installazione di numpy con pip install numpy fornisce errore Building wheel for numpy (PEP 517) ERROR: Failed building wheel for numpy Failed to build numpy ERROR: Could not build wheels for numpy which use PEP 517 and cannot be installed directly A cosa è dovuto e come devo fare per installare anche scipy che non riesce? Grazie -- https://mail.python.org/mailman/listinfo/python-list
[issue45428] py_compile fails to read filenames from stdin
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue45428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44215] help() module listing displays import warnings from deprecated package modules
New submission from Stefano Rivera :
Originally reported against pypy3 in Ubuntu
https://bugs.launchpad.net/ubuntu/+source/pypy3/+bug/1920675
$ ./python
Python 3.10.0a5+ (heads/master:ffa55d21b4, May 23 2021, 08:14:50)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append('/usr/lib/python3/dist-packages/')
>>> help()
...
help> modules
Please wait a moment while I gather a list of all available modules...
/usr/lib/python3/dist-packages/IPython/kernel/__init__.py:12: ShimWarning: The
`IPython.kernel` package has been deprecated since IPython 4.0.You should
import from ipykernel or jupyter_client instead.
warn("The `IPython.kernel` package has been deprecated since IPython 4.0."
Expected Tk Togl installation in
/usr/lib/python3/dist-packages/OpenGL/Tk/togl-linux-64
Failure loading Togl package: can't find package Togl, on debian systems this
is provided by `libtogl2`
...
Crypto brain_crypt hgext random
...
Warnings should probably be suppressed during module importing in help. Any
warnings emitted here are probably deprecation warnings or system configuration
issues, not useful to a user trying to browse modules.
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 394196
nosy: docs@python, stefanor
priority: normal
severity: normal
status: open
title: help() module listing displays import warnings from deprecated package
modules
type: behavior
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue44215>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43307] Sync site.py and sysconfig.py with PyPy
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue43307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Change by Stefano Rivera : -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
Stefano Mazzucco added the comment: Closing as this bug refers to versions of Python that have been EOL'd. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue24599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)
Stefano Rivera added the comment: On Linux, the reproducer in https://bugs.python.org/issue38501#msg354813 fails on ac10e0c93218627d1a639db0b7b41714c5f6a883^ and passes on ac10e0c93218627d1a639db0b7b41714c5f6a883, which is why I say PR 19009 fixes it. Not sure if there are any special considerations for Windows here. HEAD is good too. So from my PoV, good to close this. -- ___ Python tracker <https://bugs.python.org/issue38501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)
Stefano Rivera added the comment: Looks like it was fixed by PR 19009 (bpo-39360)). -- ___ Python tracker <https://bugs.python.org/issue38501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to be notified on worker exit
Stefano Rivera added the comment: This change seems to be causing a deadlock in multiprocessing shut-down: bpo-38501 -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue35493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38501] multiprocessing.Pool hangs atexit (and garbage collection sometimes)
Stefano Rivera added the comment: A bisect points at https://github.com/python/cpython/pull/11488 being the change that introduced this hang (bpo-35493) -- nosy: +stefanor ___ Python tracker <https://bugs.python.org/issue38501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35832] Installation error
Stefano Bonalumi added the comment:
Hi
plesaes find these files attached
Please give me further instructions
Thanks a lot
Il giorno sab 26 gen 2019 alle ore 16:21 Steve Dower
ha scritto:
>
> Steve Dower added the comment:
>
> You should have a set of log files in your %TEMP% directory. Their names
> will start with Python and end in .log. If you could collect these into a
> zip file and post them here, that would be very helpful.
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue35832>
> ___
>
--
Added file: https://bugs.python.org/file48080/Python 3.7.0
(64-bit)_20190127100020.log
Added file: https://bugs.python.org/file48081/Python 3.7.2
(32-bit)_20190127100056.log
___
Python tracker
<https://bugs.python.org/issue35832>
___[1AC8:289C][2019-01-27T10:00:20]i001: Burn v3.11.1.2318, Windows v10.0 (Build
17763: Service Pack 0), path:
C:\Users\Admin\AppData\Local\Temp\{8B2A7EA8-B5D7-44A3-856A-29C72168}\.cr\python-3.7.0-amd64.exe
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'ActionLikeInstalling' to value 'Installing'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'ActionLikeInstallation' to value 'Setup'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'ShortVersion' to value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'ShortVersionNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'WinVer' to
value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'WinVerNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'InstallAllUsers' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'InstallLauncherAllUsers' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetDir'
to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'DefaultAllUsersTargetDir' to value '[ProgramFiles64Folder]Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'TargetPlatform' to value 'x64'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'DefaultJustForMeTargetDir' to value
'[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'OptionalFeaturesRegistryKey' to value
'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'TargetDirRegistryKey' to value
'Software\Python\PythonCore\[WinVer]\InstallPath'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'DefaultCustomTargetDir' to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'InstallAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'InstallLauncherAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'TargetDirState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'CustomBrowseButtonState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_core' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_exe' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_dev' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_lib' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_test' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_doc' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_tools' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_tcltk' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_pip' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_launcher' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable
'Include_launcherState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_symbols' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'Include_debug' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'LauncherOnly' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable
'DetectedLauncher' to value
[issue35832] Installation error
New submission from Stefano Bonalumi : Hi i get the following installation error code when i try to install python 3.7.2 version on Windows 10 See the attached files -- components: Installation files: Annotazione 2019-01-26 132044.jpg messages: 334390 nosy: Stefano Bonalumi priority: normal severity: normal status: open title: Installation error type: crash versions: Python 3.7 Added file: https://bugs.python.org/file48078/Annotazione 2019-01-26 132044.jpg ___ Python tracker <https://bugs.python.org/issue35832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28401] Don't support the PEP384 stable ABI in pydebug builds
Stefano Rivera added the comment: > whether this would confuse users since they will simply get an ImportError > instead of some other error and thus will they be able to realize why there's > a problem? It's the same behaviour we have for any other module on the import path, that doesn't have the right tag. I suppose abi3 is a bit of a special case there, because it's expected to be widely supported... Also, there is a related problem: Because abi3 is in the supported extension list, setup.py build will build an abi3 extension (which isn't actually abi3), under a pydebug interpreter. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28401] Don't support the PEP384 stable ABI in pydebug builds
Stefano Rivera added the comment: I wouldn't say it's *entirely* Debian-specific. It just bites anyone who actually needs these tags to differentiate between built extensions. (Mostly Debian) Yes, changing the tag is a more complete solution. It just seemed that that option was decided against, in the relevant PEPs. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28401] Don't support the PEP384 stable ABI in pydebug builds
New submission from Stefano Rivera: setup.py build for a library using py_limited_api will always generate a stable ABI tagged shared library, even under the pydebug interpreter. This means that extensions that are built for a pydebug interpreter may be accidentally (and brokenly) imported in a non-dbg interpreter and vice-versa. e.g. in python-librtmp, with cffi 1.8.3: $ python3-dbg setup.py build ... x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,relro -g -Og -fdebug-prefix-map=/build/python3.5-H9Fri6/python3.5-3.5.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.5-pydebug/build/temp.linux-x86_64-3.5-pydebug/librtmp._librtmp.o -lrtmp -o build/lib.linux-x86_64-3.5-pydebug/librtmp/_librtmp.abi3.so Then: $ cd build/lib.linux-x86_64-3.5-pydebug $ python3 -c 'import librtmp' Traceback (most recent call last): File "", line 1, in File "/tmp/python-librtmp-0.3.0/build/lib.linux-x86_64-3.5-pydebug/librtmp/__init__.py", line 8, in from ._librtmp import ffi, lib as librtmp ImportError: /tmp/python-librtmp-0.3.0/build/lib.linux-x86_64-3.5-pydebug/librtmp/_librtmp.abi3.so: undefined symbol: _Py_RefTotal setuptools decides whether to use the stable ABI, by looking at imp.get_suffixes(). And obviously, the importer is looking at that too. So, the stable ABI tag should simply not be in there. PEP3149 agrees with this. It has this quote from Martin v. Löwis: --with-pydebug would not be supported by the stable ABI because this changes the layout of PyObject , which is an exposed structure. So, here's a patch, to disable support for the stable ABI under pydebug builds. -- components: Library (Lib) files: pep384-pydbg.patch keywords: patch messages: 278381 nosy: stefanor priority: normal severity: normal status: open title: Don't support the PEP384 stable ABI in pydebug builds type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45040/pep384-pydbg.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117601] os.path.exists returns false negatives in MAC environments.
Stefano Mazzucco added the comment: FWIW, I have just been experiencing this on CentOS 6.5 with Python 2.7.5 (sorry). I could make the Python code happy by running chcon[1] with the correct context type, otherwise os.path.exists would happily return False for a file that actually existed. [1] https://fedoraproject.org/wiki/SELinux/chcon -- nosy: +stefano-m ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1117601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Changes by Stefano Taschini <tasch...@ieee.org>: -- nosy: +taschini ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
Stefano Mazzucco added the comment: Any thoughts from the core Python developers? It seems to me that this is a confirmed bug with a working fix (that may need further review, but indeed works). So, hopefully, this issue could be resolved fairly quickly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
Stefano Mazzucco added the comment:
Martin, thanks for elaborating my thoughts!
I have dug I bit deeper in Python2's urllib code with pdb, and I think I have
narrowed the issue down to what open_http does.
In my example code, replacing opener.open(url) with opener.open_http(url) gives
the same problem.
I realize I did not provide you with the output of the script, so here it is:
* Python 2.7.10
python urllib_error.py
('Trying to open', 'https://www.python.org')
Traceback (most recent call last):
File urllib_error.py, line 30, in module
opener.open_http((host, selector))
File /home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py, line
364, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File /home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py, line
381, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File /home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py, line
386, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 501, 'Not Implemented', httplib.HTTPMessage instance
at 0x7f875a67b950)
* Python 3.4.3
python urllib_error.py
Trying to open https://www.python.org
Traceback (most recent call last):
File urllib_error.py, line 30, in module
opener.open_http((host, selector))
File /home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py,
line 1805, in open_http
return self._open_generic_http(http.client.HTTPConnection, url, data)
File /home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py,
line 1801, in _open_generic_http
response.status, response.reason, response.msg, data)
File /home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py,
line 1821, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File /home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py,
line 1826, in http_error_default
raise HTTPError(url, errcode, errmsg, headers, None)
urllib.error.HTTPError: HTTP Error 501: Not Implemented
When I unwrap the contents of httplib.HTTPMessage, the error page returned by
the squid proxy says:
---
ERROR
The requested URL could not be retrieved
The following error was encountered while trying to retrieve the URL:
https://www.python.org
Unsupported Request Method and Protocol
Squid does not support all request methods for all access protocols. For
example, you can not POST a Gopher request.
---
Looking at Python2's implementation of URLopener's open_http, I can get an even
more minimal failing example limited to httplib:
import httplib
host = 'proxy.corp.com:8181' # this is not the actual proxy
selector = 'https://www.python.org'
print(Trying to open, selector)
h = httplib.HTTP(host)
h.putrequest('GET', selector)
h.putheader('User-Agent', 'Python-urllib/1.17')
h.endheaders(None)
errcode, errmsg, headers = h.getreply()
print(errcode, errmsg)
print(headers.items())
Running the script on Python 2.7.10 prints:
('Trying to open', 'https://www.python.org')
(501, 'Not Implemented')
[('content-length', '3069'), ('via', '1.0 proxy.corp.com (squid/3.1.6)'),
('x-cache', 'MISS from proxy.corp.com'), ('content-language', 'en'),
('x-squid-error', 'ERR_UNSUP_REQ 0'), ('x-cache-lookup', 'NONE from
proxy.corp.com:8181'), ('vary', 'Accept-Language'), ('server', 'squid/3.1.6'),
('proxy-connection', 'close'), ('date', 'Fri, 10 Jul 2015 09:27:14 GMT'),
('content-type', 'text/html'), ('mime-version', '1.0')]
As I said, I found out about this when using buildout to download files over
HTTPS.
Buildout uses urllib.urlretrieve on Python2 and urllib.request.urlretrieve on
Python3. I guess that the latter has been fixed in issue 1424152, so that's why
I can download with buildout on Python3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24599
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
Stefano Mazzucco added the comment: Martin, I have applied the patch https://bugs.python.org/file31201 to my Python2.7.10 installation and seem to work OK. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
Stefano Mazzucco added the comment: I have run the minimal example provided on both Python2 and Python3 with the same results. Sorry if that was not clear. I did look at issue 1424152 but it seemed to me that I was experiencing a different problem. When I try and open the page, I get a squid error page with a somewhat vague error saying that the method is not supported (even though it's a simple GET and I can get the same page with other tools like wget or a web browser). Unfortunately, I don't have access to the proxied environment right now, and I will need to ask for the squid logs anyway since I can't access them. I have to say that I have experienced this problem while using buildout as zc.buildout.download uses urllib.urlretrieve. Surprisingly, it succeeds on Python3, but it fails with Python2 which is our supported version (so there's currently no way that I can use Python3 at work). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http://
New submission from Stefano Mazzucco: Hello, at work, I am behind a proxy (squid) that is only available over http. So, I have to configure both the http_proxy and https_proxy environment variables to be something like http://proxy.corp.com:8181; Now, when I try and use urllib to open an https url, the proxy returns 501 Not Implemented. The quick and dirty script below is a minimal demonstration of the problem that appears on both python 2.7 (tested on 2.7.6, 2.7.9, 2.7.10) and 3.4 (tested on 3.4.0 and 3.4.4) try: import urllib opener = urllib.URLopener() except AttributeError: # Python 3 import urllib.request opener = urllib.request.URLopener() url = 'https://www.python.org' print(Trying to open, url) opener.open(url) Changing the url to http://; works OK. Thanks, -- Stefano -- components: Library (Lib) messages: 246515 nosy: stefano-m priority: normal severity: normal status: open title: urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24599 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
mds-utils 2.1.1 released
I am pleased to announce the release of mds-utils 2.1.1 http://www.micheledestefano.joomlafree.it/en/mds-utils.html. This release fixes small bugs present into the 2.1.0 release. Users are strongly encouraged to upgrade to this version. Features summary --- MDS-UTILS provides: 1. a tool for detecting machine endianity. 2. utilities for the Boost uBLAS library. Amongst them, some type traits for detecting different uBLAS matrix types. 3. some useful classes that allow to treat the old C FILE pointer as a C++ stream. 4. C++ wrappers of the main Python objects, independent of those in Boost Python. Wrappers are provided also for NumPy arrays. 5. C++ classes that help on treating Python file objects as C++ streams. 6. a review and refactor of the indexing support in Python extensions. Now access in write mode is supported too. 7. new C++ *to-Python* and *from-Python* converters for some *Boost uBlas* objects and for standard Python objects. These converters do not depend on Boost Python. 8. a new sequence iterator that is able to wrap Python sequences and allows also to modify them. This feature does not depend on Boost.Python. 9. the NDArrayIterator class, that wraps the Numpy C-API iterator and allows easy management of conversions to/from Numpy arrays. 10. some SWIG interface files, for easy integration with SWIG extensions for Python. Each class is a well-documented, small, easy to use and it should never be too difficult to learn to use it. A large percentage of this library makes a heavy usage of the Boost C++ libraries http://www.boost.org/: so, they must be installed on the system. It is assumed that the user is familiar with them. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
mds-utils 2.1.0 released
I am pleased to announce the release of mds-utils 2.1.0 http://www.micheledestefano.joomlafree.it/en/mds-utils.html. Features summary --- MDS-UTILS provides: 1. a tool for detecting machine endianity. 2. utilities for the Boost uBLAS library. Amongst them, some type traits for detecting different uBLAS matrix types. 3. some useful classes that allow to treat the old C FILE pointer as a C++ stream. 4. C++ wrappers of the main Python objects, independent of those in Boost Python. Wrappers are provided also for NumPy arrays. 5. C++ classes that help on treating Python file objects as C++ streams. 6. a review and refactor of the indexing support in Python extensions. Now access in write mode is supported too. 7. new C++ *to-Python* and *from-Python* converters for some *Boost uBlas* objects and for standard Python objects. These converters do not depend on Boost Python. 8. a new sequence iterator that is able to wrap Python sequences and allows also to modify them. This feature does not depend on Boost.Python. 9. the NDArrayIterator class, that wraps the Numpy C-API iterator and allows easy management of conversions to/from Numpy arrays. 10. some SWIG interface files, for easy integration with SWIG extensions for Python. Each class is a well-documented, small, easy to use and it should never be too difficult to learn to use it. A large percentage of this library makes a heavy usage of the Boost C++ libraries http://www.boost.org/: so, they must be installed on the system. It is assumed that the user is familiar with them. Michele De Stefano -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
mds-utils 2.0.0 released
I am pleased to announce the release of mds-utils 2.0.0 http://www.micheledestefano.joomlafree.it/en/mds-utils.html. MDS-UTILS provides: 1. a tool for detecting machine endianity. 2. utilities for the Boost uBLAS library. Amongst them, some type traits for detecting different uBLAS matrix types. 3. some useful classes that allow to treat the old C FILE pointer as a C++ stream. 4. C++ wrappers of the main Python objects, independent of those in Boost Python. 5. C++ classes that help on treating Python file objects as C++ streams. 6. a review and refactor of the indexing support in Python extensions. Now access in write mode is supported too. 7. new C++ *to-Python* and *from-Python* converters for some *Boost uBlas* objects and for standard Python objects. These converters do not depend on Boost Python. 8. a new sequence iterator that is able to wrap Python sequences and allows also to modify them. This feature does not depend on Boost.Python. 9. the NDArrayIterator class, that wraps the Numpy C-API iterator and allows easy management of conversions to/from Numpy arrays. 10. some SWIG interface files, for easy integration with SWIG extensions for Python. The easiest way to learn to use this library is to browse the modules section and look at the usage examples. Each class is a well-documented, small, easy to use tool and it should never be too difficult to learn to use it. A large percentage of this library makes a heavy usage of the Boost C++ libraries http://www.boost.org/: so, they must be installed on the system. It is assumed that the user is familiar with them. With respect to the previous releases, this one has been completely rewritten in order to be independent of Boost Python. The recommended usage for Python extensions development is now through SWIG. -- Michele De Stefano Web Site http://www.micheledestefano.joomlafree.it Linked In http://it.linkedin.com/in/micheledestefano mds-utils: a general purpose Open Source library http://www.micheledestefano.joomlafree.it/en/mds-utils.html http://it.linkedin.com/in/micheledestefano -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue21772] platform.uname() not EINTR safe
Stefano Borini added the comment: You can't use subprocess. platform is used during build. subprocess needs select, but select is a compiled module and at that specific time in the build process is not compiled yet. -- nosy: +stefanoborini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21772 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21772] platform.uname() not EINTR safe
Stefano Borini added the comment: Wouldn't it make sense to use the same strategy used in the subprocess fix (that is, retry?). See http://hg.python.org/cpython/rev/6e664bcc958d/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21772 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes
Stefano Lattarini added the comment: Since I too was bitten by this issue, I'd like to support Gregory's request, and report my rationale for changing the current behaviour. With the current behaviour, we could see (and I *have* seen) scenarios like this: 1. A test exposing a known bug is written, and the test is marked as expected failure. 2. Some refactoring and code improvements follow. 3. They improve the overall behaviour/correctness of the program or library under test, to the point of fixing the bug behind the scenes. 4. The developer doesn't notice the fix though, since the testing framework doesn't warn him strongly enough of the fact that the test marked as expected failure has begun to pass. (To reiterate, the current behaviour of just printing a warning saying some test passed unexpectedly on the standard output is not good enough of a warning; it's easy to miss, and worse, it's *certain* that it will be missed if the tests are run by some CI systems or a similar wrapper system -- those would only report failures due to non-zero exit statuses.) 5. Without noticing that the issue has been fixed, the developer does some further changes, which again re-introduce the bug, or a similar one that the test still marked as expected failure could easily catch. 6. That test starts to fail again; but since it has remained marked as expected failure all along, the fact is not reported to the developer in any way. So the bug has managed to sneak back in, unnoticed. In addition to this rationale, another (weaker) reason to change the existing behaviour would be the principle of least surprise. Among other widely used testing framework (for python, or language-agnostic) many of those which support the concept of expected failure will throw hard errors by default when a test marked as expected failure starts to pass; among these are: * Python libs: - py.test (http://pytest.org) - Nose (https://pypi.python.org/pypi/nose/1.3.0) * Language-agnostic protocols/frameworks: - the TAP protocol (the standard in the Perl world) (http://en.wikipedia.org/wiki/Test_Anything_Protocol) - the Automake Simple Tests framework (http://www.gnu.org/software/automake/manual/html_node/Tests.html) -- nosy: +slattarini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20165 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
mds-utils 1.3.0 release
After 3 years of no enhancement I'm pleased to announce a new release of the mds-utils http://code.google.com/p/mds-utils library (general purpose utilities for C++ and Python developers). The library contains useful C++ code for developing Python extensions through Boost.Python but also through SWIG or the simple C API. At present mds-utils contains: 1. a tool for detecting machine endianity. 2. some useful classes that allow to treat the old C FILE pointer as a C++ stream. 3. C++ classes that help on treating Python file objects as C++ streams. 4. simple utilities for indexing support in Python extensions. 5. new C++ to-Python and from-Python converters for some Boost uBlas objects. 6. a new sequence iterator that is able to wrap Python sequences and allows also to modify them. This feature does not depend on Boost.Python. 7. new from/to Python conversion utilities that do not depend on Boost.Python. Furthermore, the new release has been tested with Python 2.7.3 too, while the previous one had some issues with Python = 2.5. Best regards to all. -- Michele De Stefano Web Site http://www.micheledestefano.joomlafree.it Linked In http://it.linkedin.com/in/micheledestefano mds-utils: a general purpose Open Source libraryhttp://code.google.com/p/mds-utils http://it.linkedin.com/in/micheledestefano -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue8767] Configure: Cannot disable unicode
Stefano Taschini tasch...@ieee.org added the comment: Understood and agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8767] Configure: Cannot disable unicode
Stefano Taschini tasch...@ieee.org added the comment: Martin, That was exactly my first approach. What made me change my mind is that i) it is also fairly hacky (one might rightfully object that it is the isinstance(x, unicode) tests that should be changed) ii) it is now a hack spread over a dozen files, instead of the site.py alone. iii) the alterations in those files are executed even in the case of built-in unicode support, thus increasing the risk of introducing a regression in the stdlib. In the end I was a bit loath to alter quite a few of the stdlib modules (including some of the core ones) for a rather infrequent case. My solution, on the other hand, is such that in the regular case of built-in unicode support those modules are not touched at all, thus reducing the risk of introducing a regression in the stdlib. Still, if you guys do think that the maintainability risk due to the hackiness of my suggestion exceeds the potential benefits, it might be better to split the issue (and the patch) into two: one for the autoconf and interpreter, and one for the stdlib. In this way, the patch for autconf and interpreter (which should be less controversial) might be accepted sooner, while we bide our time until we come up with a better solution for the stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8767] Configure: Cannot disable unicode
Changes by Stefano Taschini tasch...@ieee.org: Added file: http://bugs.python.org/file25418/issue8767_interpreter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8767] Configure: Cannot disable unicode
Stefano Taschini tasch...@ieee.org added the comment: Here we go. -- Added file: http://bugs.python.org/file25419/issue8767_stdlib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12947] Examples in library/doctest.html lack the flags
Stefano Taschini tasch...@ieee.org added the comment: Ezio, the patch I attached goes into that direction, by adding a :trim-doctest-flags: disable option to the code blocks. I thought I had a good reason for having the option worded as :trim-doctest-flags: disable instead of :keep-doctest-flags:, now I'm not so sure. Note: the patch is against the 2.7 branch. -- keywords: +patch Added file: http://bugs.python.org/file25424/issue12947_v0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8767] Configure: Cannot disable unicode
Stefano Taschini tasch...@ieee.org added the comment: Here's the patch. It has four goals: 1. Allow ./configure --disable-unicode to work; 2. Have the naked interpreter running with no unicode support; 3. Be able to compile most of the stdlib; 4. Be able to run the test suite. The one-line modification to configure.ac (and consequentley autoreconf'ed configure) achieve goal 1. The changes to the three C files (which are nothing more than a few #ifdef Py_USING_UNICODE) achieve goal 2: you can run ./python -S. The fix for site.py takes care of posixpath, glob, (and a few other modules) and makes it possible to compile most of the C extensions of the stdlib, goal 3 -- The compilation process under posix requires posixpath and glob to work. The most notable extension that won't be built is, unsurprisingly enough, io. Fortunately it does not play in Python 2.7 the central role it plays in Python 3. Still, a few other modules depend on it and won't be usable. The changes in Lib/test/script_helper.py and Lib/test/test_support.py make it possible to run the test suite. Roughly one third of the tests will fail, though, but I think that's acceptable. In relation to my purpose for submitting this patch ( #1065986 ) , I note that test_pydoc runs and succeeds. -- keywords: +patch Added file: http://bugs.python.org/file25377/issue8767.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065986] Fix pydoc crashing on unicode strings
Stefano Taschini tasch...@ieee.org added the comment: Here's my patch, along the lines of the work-around I posted earlier. A few remarks: 1. The modifications in pydoc only touch the four console pagers and the html pager (html.page). 2. A module-wide default encoding is initialized from locale.getpreferredencoding. Pagers that write to a file use the encoding of that file if defined, else they use the module-wide default. The html pager uses ascii. All of them use xml character entity replacement as fall-back. 3. An additional set of tests has been added to test.test_pydoc to verify the behaviour of the modifications. 4. No functionality is broken if Python is built without unicode support. -- Added file: http://bugs.python.org/file25380/issue1065986.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1065986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8767] Configure: Cannot disable unicode
Changes by Stefano Taschini tasch...@ieee.org: -- nosy: +taschini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065986] Fix pydoc crashing on unicode strings
Stefano Taschini tasch...@ieee.org added the comment: Shouldn't this be reopened for Python 2.7 ? -- type: - behavior versions: +Python 2.7 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1065986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065986] Fix pydoc crashing on unicode strings
Stefano Taschini tasch...@ieee.org added the comment: Oh well, in that case I guess we'll have to work around it. Here's the monkey patch I use to overcome this limitation in pydoc, in case others wish to add it to their PYTHONSTARTUP or sitecustomize: def pipepager(text, cmd): Page through text by feeding it to another program. try: import locale except ImportError: encoding = ascii else: encoding = locale.getpreferredencoding() pipe = os.popen(cmd, 'w') try: pipe.write(text.encode(encoding, 'xmlcharrefreplace') if isinstance(text, unicode) else text) pipe.close() except IOError: pass # Ignore broken pipes caused by quitting the pager program. import pydoc pydoc.pipepager = pipepager del pydoc, pipepager -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1065986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1065986] Fix pydoc crashing on unicode strings
Changes by Stefano Taschini tasch...@ieee.org: -- nosy: +taschini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1065986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14611] inspect.getargs fails on some anonymous tuples
Stefano Taschini tasch...@ieee.org added the comment: I think this should do. inspect.getargs is now looking for STORE_DEREF besides STORE_FAST, and is making sure that the appropriate namespace (locals vs cell + free vars) is selected depending on the opcode. The only changes to the test suite are three additional tests, based on the two examples above. -- keywords: +patch Added file: http://bugs.python.org/file25269/issue_14611.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12947] Examples in library/doctest.html lack the flags
Stefano Taschini tasch...@ieee.org added the comment: As far as I can see, Sphinx has a global setting for trim_doctest_flags but lacks the possibility of locally disabling the trimming. A quick workaround would be to have the following sphinx extension added: class ProxyLexer(object): def __init__(self, underlying): self.__underlying = underlying def __getattr__(self, attr): return getattr(self.__underlying, attr) def setup(app): from sphinx.highlighting import lexers if lexers is not None: lexers['pycon-literal'] = ProxyLexer(lexers['pycon']) lexers['pycon3-literal'] = ProxyLexer(lexers['pycon3']) That would allow blocks marked as .. code-block:: pycon-literal or preceded by .. highlight:: pycon-literal to escape the trimming of doctest flags. If that's of any interest I can submit a patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14611] inspect.getargs fails on some anonymous tuples
New submission from Stefano Taschini tasch...@ieee.org: How to reproduce Take the following two functions: def f(l, (x, y)): ...sup = max(u*x + v*y for u, v in l) ...return ((u, v) for u, v in l if u*x + v*y == sup) def g((x, y)): ...def h(): ...return x + y ...return h Inspect.getargs will throw an exception on the former and return a wrong result on the latter:: import inspect inspect.getargs(f.__code__) Traceback (most recent call last): ... IndexError: list index out of range inspect.getargs(g.__code__) Arguments(args=['h'], varargs=None, keywords=None) # h is most definitely not an argument of g! Analysis If you disassemble the two functions, you'll see that in both cases the anonymous tuples are unpacked using STORE_DEREF:: import dis dis.disassemble(f.__code__) 1 0 LOAD_FAST1 (.1) 3 UNPACK_SEQUENCE 2 6 STORE_DEREF 0 (x) 9 STORE_DEREF 2 (y) BLANKLINE 2 12 LOAD_GLOBAL 0 (max) ... dis.disassemble(g.__code__) 1 0 LOAD_FAST0 (.0) 3 UNPACK_SEQUENCE 2 6 STORE_DEREF 0 (x) 9 STORE_DEREF 1 (y) BLANKLINE 2 12 LOAD_CLOSURE 1 (y) 15 LOAD_CLOSURE 0 (x) 18 BUILD_TUPLE 2 21 LOAD_CONST 1 (code object h ...) 24 MAKE_CLOSURE 0 27 STORE_FAST 3 (h) BLANKLINE 4 30 LOAD_FAST3 (h) 33 RETURN_VALUE\ However, the implementation of inspect.getargs only looks for UNPACK_TUPLE, UNPACK_SEQUENCE, STORE_FAST. Notes - The version of Python used is:: import sys sys.version_info[:3] (2, 7, 3) -- components: Library (Lib) messages: 158599 nosy: taschini priority: normal severity: normal status: open title: inspect.getargs fails on some anonymous tuples type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12947] Examples in library/doctest.html lack the flags
Stefano Taschini tasch...@ieee.org added the comment: Concrete examples can be seen in the section http://docs.python.org/library/doctest.html#option-flags-and-directives For instance at http://docs.python.org/library/doctest.html#doctest.IGNORE_EXCEPTION_DETAIL The doctest flags present in the sources in http://docs.python.org/_sources/library/doctest.txt are all stripped. -- nosy: +taschini ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14611] inspect.getargs fails on some anonymous tuples
Stefano Taschini tasch...@ieee.org added the comment: I'll give it a try. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
Changes by Stefano Rivera pyt...@rivera.za.net: -- nosy: +stefanor ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3990] The Linux2 platform definition is incorrect for alpha, hppa, mips, sparc
Changes by Stefano Rivera pyt...@rivera.za.net: -- nosy: +stefanor ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Convenient filtering in for cycles
Dear all, I would like to know if there is a (more) convenient way of doing this structure: ===(1)=== for x in l: if P(x): do_stuff(x) == Let's say that my dream syntax would be ===(2)=== for x in l if P(x): do_stuff(x) == as if it was the second part of a list comprehension. But sadly it is not in the language. Obvious alternatives are ===(3)=== for x in (x for x in l if P(x)): do_stuff(x) == ===(4)=== for x in l: if not P(x): continue do_stuff(x) == ===(5)=== [do_stuff(x) for x in l if P(x)] == As I see it, every syntax-valid solution has its drawbacks: (1) adds an indentation level; (3) adds an unnatural repetition of variable names and for; (4) has the masked goto continue (even if it is quite easy to understand what happens); (5) is good but not usable when do_stuff is what it usually is, that is a list of instructions. Is there some better and valid construction I missed? If not, is there a reason why (2) is not in the language? Pardon my boldness, but I am asking this because there are two invalid construct that I keep writing when I don't pay attention: one is (2), and the other is list comprehensions as in ===(6)=== for x in (x in l if P(x)): do_stuff(x) == which accidentally would be a better solution than (1), (3), (4), (5), though not as good as (2). Thank you for your attention, Stefano Maggiolo -- http://mail.python.org/mailman/listinfo/python-list
Re: Convenient filtering in for cycles
Dear Ian, thank you for you kind response. I was pretty confident the issue had already been discussed, but I was unable to look it up. I suppose your filter syntax is the best given the options (I always forget about map and filter...) and definitely I see that the work needed to add such a feature is hardly worth the convenience. Still, I think it is sad that generators/list comprehensions and for cycles do not share the same syntax. Unfortunately, this example from one of your links convinces that anyway it is too late: (x for x in (l1 if c else l2)) # valid (x for x in l1 if c else l2) # SyntaxError for x in l1 if c else l2 # valid Cheers, Stefano -- http://mail.python.org/mailman/listinfo/python-list
New mds-utils release (1.2.0)
mds-utils 1.2.0 have been released. Release Notes: - Improved python/fileobj.hpp: now there are 3 helper file objects and they are copy-constructible. Derivation from boost::python::object has been mantained. - Added utilities for indexing support in Python extensions. - Added boost::python converters for some boost::numeric::ublas classes. --- What is mds-utils ? --- mds-utils is a library intended to become a collection of several C++ utilities. It makes heavy usage of the Boost C++ libraries. Release 1.2.0 contains: - a tool for detecting machine endianity. - some useful classes that allow to treat the old C FILE pointer as a C++ stream. - C++ classes that help on treating Python file objects as C++ streams. - simple utilities for indexing support in Python extensions. - new C++ to-Python and from-Python converters for some Boost uBlas objects. Project home: http://code.google.com/p/mds-utils/ -- Michele De Stefano http://www.linkedin.com/in/micdestefano http://xoomer.virgilio.it/michele_de_stefano -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
New mds-utils release (1.1.0)
I'm proud to announce a new release of mds-utils (http://code.google.com/p/mds-utils/). New release features: 1) flush support added to FILE* devices. 2) added a new python namespace. Contains an object derived from boost::python::object that helps in using python file objects within python extensions written with Boost.Python. What is mds-utils ? -- It's a C++ library composed by different utilities. Amongst its features it contains classes to treat a FILE* as a C++ stream. It contains also some utilities for developing C++ Python extensions. For more information, go to the library site (http://code.google.com/p/mds-utils/) -- Michele De Stefano http://www.linkedin.com/in/micdestefano http://xoomer.virgilio.it/michele_de_stefano -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Treat C FILE* as C++ streams
Hello to everyone. I'm an Italian engineer and I'm approaching to Python, particularly to Python extension through C++ (because I'm an experienced C++ programmer). I've seen that Python files are basically managed through the C FILE pointer. I've recently released on Google Code a very small library which allows to treat the C FILE* as a C++ stream and I think this should be useful to Python developers. The link is this: http://code.google.com/p/mds-utils/ The library uses Boost.Iostreams. Think to this situation: you have some C++ classes or functions that take a C++ stream or fstream as parameter. You want to make a Python extension from this library but you want to pass a Python file object to your C++ code. Using my library, you can wrap the underlying FILE* into an object that behaves like a C++ stream. I've not yet built an on-line documentation, but the library comes with detailed doxygen documentation and useful examples. I hope my library will be useful to the Python community and I'd like to see a link to it on the Python web site. Best regards to all of you. Michele -- Michele De Stefano http://www.linkedin.com/in/micdestefano http://xoomer.virgilio.it/michele_de_stefano -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: package with executable
Il Wed, 20 May 2009 07:01:39 +0100, A. Cavallo ha scritto: With the standard distutils (no need for setuptools) the config.py file might look like: Right, I ended up using setuptools just because I used paster to create the project layout. I'll think about using plain distutils instead. import gnucal must work. If you're developing from the sources (eg. without having the package installed) you need to be in the same dir where the gnucal.py is or you need to set PYTHONPATH in order to find the directory gnucal (the one containing __init__.py). Right now, the problem is that upon installing import gnucal works in the python interactive interpreter, but gnucal.py raises an exception that it's not able to import gnucal.core and friends. At line 101 the statement sys.exit(Please.. should be parser.error(Please.. Good point! Thanks, steko -- http://mail.python.org/mailman/listinfo/python-list
package with executable
Hi, my name is Stefano Costa, I am an archaeologist and I am developing GNUCal, a radiocarbon calibration program released under the GNU GPL. [1][2] Currently the program consists of a small library, largely based on Matplotlib and Numpy, and a command line program. My goal is to create a distributable package, that should ideally contain both the gnucal package and the command line program. As you can see in the source code [3], I am following some sort of standard layout for my project, but some things aren't still clear to me, even after reading setuptools' documentation and looking to the source of some known Python packages (like sphinx, pastescript, django): * where should the executable module be wrt setup.py and/or the package directory in the source tree * how should I format the console_scripts entry in setup() to make the executable module available to the system PATH after installing * how should I call the gnucal package from inside the executable script (currently I'm using from gnucal import core but it doesn't seem to work) I'm using virtualenv to create testing environments for the install process, and my Python is 2.5.4 on Debian Sid. Any suggestion is appreciated, particularly if there are some real examples to draw from. thanks, steko [1] http://gnucal.iosa.it/ [2] http://en.wikipedia.org/wiki/Radiocarbon_dating#Calibration [3] http://bitbucket.org/steko/gnucal/ -- Stefano Costa http://www.iosa.it/ Open Archaeology signature.asc Description: Questa è una parte del messaggio firmata digitalmente -- http://mail.python.org/mailman/listinfo/python-list
SqlAlchemy and mssqlserver
Using sqlalchemy with pyodbc and mssqlserver
Why sa always generate identity ?
many thanks here the sample
tb = Table('prova',meta,Column('chiave', Integer, primary_key=True))
tb.create()
CREATE TABLE prova (
chiave INTEGER NOT NULL IDENTITY(1,1),
PRIMARY KEY (chiave)
)
Stefano
--
http://mail.python.org/mailman/listinfo/python-list
script question
I have a script like this myscript.py def func01() def func02() def func03() def funcnn() How can i execute my func in the code ? import myscript for i in range(1,n): myscript.func?? many thanks stefano -- http://mail.python.org/mailman/listinfo/python-list
wx, qt, gtk
Hello everybody After many little programs now I must prepare a serious desktop application . Without discussing about licensing but only from the technical point of view I have tried wx,wt,gtk graphical gui to build 'normal gui apps ' and everyone goes well. In the end of all i searched in internet and i've found that applications ( even commercial ) written with gtk are more and more than other written with wx and qt (not only with python) Any commets are appreciated Stefano -- http://mail.python.org/mailman/listinfo/python-list
How to assign a function to another function
Hi all what i'm trying to do is this: def foo (): ... return None ... def bar (): ... print called bar ... def assigner (): ... foo = bar ... assigner() foo() called bar This piece of code is not working and even trying with def assigner (a, b): ... a = b ... assigner(foo, bar) foo() isn't working. How can I achieve my goal? Thanks for your help! :) -- Stefano Esposito [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How to assign a function to another function
On Mon, 17 Sep 2007 17:49:58 +0100 Paul Rudin [EMAIL PROTECTED] wrote: Stefano Esposito [EMAIL PROTECTED] writes: Hi all what i'm trying to do is this: def foo (): ... return None ... def bar (): ... print called bar ... def assigner (): ... foo = bar ... assigner() foo() called bar This piece of code is not working and even trying with... ... How can I achieve my goal? By adding the line: global foo at the beginning of the body of assigner. This worked, thanks a lot :) -- Stefano Esposito [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
make images with python
I need make some images using python but i'm lost :P i need some module to make .png (with drawline, drawcircle, drawpoint etc etc etc ) like gd for php :P thants :D -- http://mail.python.org/mailman/listinfo/python-list
Re: http client module
On 31 jul, 23:07, Steve Holden [EMAIL PROTECTED] wrote: stefano wrote: Hello i'm looking for a http client for python i found this one call httplib2 http://64.233.169.104/search?q=cache:0jJWNfodK6gJ:bitworking.org/proj... but is too old Look at urllib and urllib2 in the standard library. If they don't give you what you want, think about using mechanize and ClientForm, or possible beautifulsoup, all of which Google should be able to find for you. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - thanks -- http://mail.python.org/mailman/listinfo/python-list
http client module
Hello i'm looking for a http client for python i found this one call httplib2 http://64.233.169.104/search?q=cache:0jJWNfodK6gJ:bitworking.org/projects/httplib2/+httplib2+pythonhl=esct=clnkcd=1gl=clclient=firefox-a but is too old -- http://mail.python.org/mailman/listinfo/python-list
Re: Python tutorials
On 29 Mag, 09:08, Laurentiu [EMAIL PROTECTED] wrote: Hello! i was searching the net for some python video tutorials (free and payed). i found some interesting stuff atwww.showmedo.combut i want something more complex. can someone give me some address for python video tutorials or companies how made this tutorials, free or payed. i search at Lynda.com and vtc but i didn't find any python references. thanks for all answers. Laurentiu Have you tried: http://www.cs.luc.edu/~anh/python/hands-on/handsonHtml/handson.html http://diveintopython.org/ Bye sc -- http://mail.python.org/mailman/listinfo/python-list
Re: gui application on cross platform
On 28 Mag, 09:28, james_027 [EMAIL PROTECTED] wrote: On May 28, 3:06 pm, Stefano Canepa [EMAIL PROTECTED] wrote: On 28 Mag, 08:01, james_027 [EMAIL PROTECTED] wrote: Hi, I am using delphi to develop gui application, and wish to make a shift to python. here are some of my question/concern... 1. is python develop gui application a cross platform? just like java swing? Yes. Qt, wxwidgets and pygtk run on Linux and Windows, don't know about Macs. 2. delphi makes things easy for me like coding for a specific event on a specific component, could it be the same for python? Not in the Delphi way but glade/gazpacho are good GUI designer for gtk. I have no experience with qtdesigner or the wx equivalent app. 3. are there cool library of component like in delphi available for python that will make database application more usesable? python has dbapi, all DBs look the same, python can also use ORM like SQLObjects and SQLALchemy 4. where do I start the learning curve? I did some research and I don't know which one to take among wxwdiget, pygtk, and etc. I tried wxwidgets and pygtk, then I decided to use pygtk but it could be I'll change my mind in the future. Bye sc Thanks sc, What do you mean when you say ..all DBs look the same That via dbapi you can use different DBs using the same API. what is the difference between pygtk and wxwidgets? pygtk uses GTK wxwidget use a different gui toolkit on different platform. It is probably the best crossplatform GUI. I used pyGTK simply becouse my GUI apps runs only on gnome. Bye sc -- http://mail.python.org/mailman/listinfo/python-list
Re: gui application on cross platform
On 28 Mag, 08:01, james_027 [EMAIL PROTECTED] wrote: Hi, I am using delphi to develop gui application, and wish to make a shift to python. here are some of my question/concern... 1. is python develop gui application a cross platform? just like java swing? Yes. Qt, wxwidgets and pygtk run on Linux and Windows, don't know about Macs. 2. delphi makes things easy for me like coding for a specific event on a specific component, could it be the same for python? Not in the Delphi way but glade/gazpacho are good GUI designer for gtk. I have no experience with qtdesigner or the wx equivalent app. 3. are there cool library of component like in delphi available for python that will make database application more usesable? python has dbapi, all DBs look the same, python can also use ORM like SQLObjects and SQLALchemy 4. where do I start the learning curve? I did some research and I don't know which one to take among wxwdiget, pygtk, and etc. I tried wxwidgets and pygtk, then I decided to use pygtk but it could be I'll change my mind in the future. Bye sc -- http://mail.python.org/mailman/listinfo/python-list
Re: Asynchronous XML-RPC client library?
On 29 Apr, 07:11, Jarek Zgoda [EMAIL PROTECTED] wrote: Is there anything like that? Googling yields many articles on async servers, but virtually nothing on clients. I have to talk to remote in an environment that does not allow threads... -- Jarek Zgodahttp://jpa.berlios.de/ Why don't you try twisted (http://www.twistedmatrix.com) Bye Stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Font management under win32
On 9/30/05, Roger Upole [EMAIL PROTECTED] wrote: Here's an example of how to use EnumFontFamilies: I'm trying the code you just posted, which works (thanks a lot), but I'm having another problem now. As I stated in my first post, the reason why I need to know the list of installed fonts is that I have to decide whether to further install some additional missing ones. The problem I have now, is that I don't know before hand the name of the missing fonts, I just have their .ttf or .otf files. So I'd have to somehow go inside and look for their names. Do you think that is possible with win32 extensions? thanks, stefano -- http://mail.python.org/mailman/listinfo/python-list
Font management under win32
Hi, I have a simple need, running under windows: 1) retrieve the list of installed system fonts 2) maybe install missing fonts Surprisingly for me, there seems to be no support for such a thing in python. I really hope I'm mistaken, so _please_ correct me if I'm wrong. I found out that it all boils down to a couple of win32 syscalls: EnumFontFamiliesEx and AddFontResourceEx. Unfortunately I'm no expert of win32 programming whatsoever. I asked Mark Hammond about this. While I wait for him to receive my email, I thought I'd post on the list in case someone else was interested, or had found a different solution. Indeed, win32gui does contain an EnumFontFamilies (without the trailing Ex) function, but I found no usage example, and I couldn't figure out how to use LOGFONT handles (since such a thing is required as the first parameter to the call). So I decided to punt on it and ask for wiser support. If I could get this EnumFontFamilies to work, it could already be enough, because I found a command line tool that allows me to do font installation. It's got to be some no-brainer 10 lines of C code simply calling AddFontResourceEx, but it works! So, does anybody ever had the same problem? thanks, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 10 Sep 2005 02:10:59 EDT, Tim Daneliuk [EMAIL PROTECTED] wrote: As someone who implemented their own configuration mini-language with validation, blah, blah, blah (http://www.tundraware.com/Software/tconfpy/) Well, a configuration mini language with validation and blahs is not exactly what I would call _simple_... :) so maybe it doesn't even fit into my idea of testing-stdlib, or quick and dirty section of the manual (see my other post). But certainly it would be worth mentioning in the list of available solutions under the subsection Configuration files handling. 1) The existing tool is inadequate for the task at hand and OO subclassing is overrated/overhyped to fix this problem. Even when you override base classes with your own stuff, you're still stuck with the larger *architecture* of the original design. You really can't subclass your way out of that, hence new tools to do old things spring into being. That's true, but usually only when the original design if too simple comparing to the complexity of the problem. Instead a very general solution can usually be subclassed to easily handle a simpler problem. You still have to actually understand the general and complex design in order to be able to write subclasses, so maybe one can be tempted to punt on it, and write its own simple solution. But in this case it would just be enough to propose a few solutions in the testing-stdlib: a) one simple implementation for simple problems, easy to understand, but limited. b) one complex implementation for complex problems, c) one simplified implementation for simple problems, easy to understand, but subclassed from a complex model, that leaves room for more understanding and extension just in case one needs more power. I fully understand the difficulty of reusing code, as it always forces you to a learning curve and coming to compromises. But I've also wasted a lot of time reinventing the wheel and later found stuff I could have happily lived with if I only had known. 2) It's a learning exercise. Well, so we might as well learn a little more and rewrite os.path, the time module and pickle. Right? :) 3) You don't trust the quality of the code for existing modules. (Not that *I* have this problem :-p but some people might.) That's a good point, but it really boils down to being a wise programmer on one side, being able to discern the Good from the Bad, and an active community on the other side, able to provide good solutions and improve them. If either one is missing, then a lot of bad stuff can happen, and we can't really take community decisions basing on the assumption that programmers won't be able to understand, or that the community won't be able to provide. So we might as well assume that we have good programmers and an active community. Which I think is true, by the way! So, let's talk about a way to more effectively present available solutions to our good programmers! :) cheers, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 10 Sep 2005 03:16:02 EDT, Tim Daneliuk [EMAIL PROTECTED] wrote: frameworks are unlikely to serve them well as written. I realize this is all at a level of complexity above what you had in mind, but it's easy to forget that a significant portion of the world likes/needs/benefits from things that are *not* particularly generic. This is thus reflected in the software they write. In my opinion this has got more to deal with the open source vs. proprietary debate, that I wouldn't like to talk about, since it's somewhat marginal. What I was pointing out is well summarized in the subject: Why do Pythoneers reinvent the wheel? Reinventing the wheel (too much) is Bad for both the open source community and industry. It's bad for development in general. I got the feeling that in the specific case of Python the ultimate reason for this tendency in also the same reason why this language is so much better that others for, say, fast prototyping and exploration of new ideas: it's simple. So, without taking anything out of python, I'm wondering if a richer and less formal alternative standard library would help forming a common grounds where programmers could start from in order to build better and reinvent less. If such an aid to _general_ problem solving is indeed missing (I might be wrong) from the current state of python, I don't really think the reason is related to industry. I would look for reasons elsewhere, like it beeing difficult to come out with effective decisional support in an open source community, or something like this. I can certainly see the challenge of who and how should decide what goes in the library, and what not. stefano -- http://mail.python.org/mailman/listinfo/python-list
Why do Pythoneers reinvent the wheel?
On 8 Sep 2005 08:24:50 -0700, Fuzzyman [EMAIL PROTECTED] wrote: What is pythonutils ? = ConfigObj - simple config file handling validate - validation and type conversion system listquote - string to list conversion StandOut - simple logging and output control object pathutils - for working with paths and files cgiutils - cgi helpers urlpath - functions for handling URLs odict - Ordered Dictionary Class Fuzzyman, your post reminded me of something I can't stop thinking about. Please don't take this as a critique on your work. I place myself on the same side of yours. I just wanted to share this thought with everybody had an opinion about it. I wonder how many people (including myself) have implemented their own versions of such modules, at least once in their pythonic life. I indeed have my own odict (even same name! :). My own pathutils (different name, but same stuff). My own validate... and so forth. This is just too bad. There are a few ares where everybody seems to be implementing their own stuff over and over: logging, file handling, ordered dictionaries, data serialization, and maybe a few more. I don't know what's the ultimate problem, but I think there are 3 main reasons: 1) poor communication inside the community (mhm... arguable) 2) lack of a rich standard library (I heard this more than once) 3) python is such an easy language that the I'll do it myself evil side lying hidden inside each one of us comes up a little too often, and prevents from spending more time on research of what's available. It seems to me that this tendency is hurting python, and I wonder if there is something that could be done about it. I once followed a discussion about placing one of the available third party modules for file handling inside the standard library. I can't remember its name right now, but the discussion quickly became hot with considerations about the module not being right enough to fit the standard library. The points were right, but in some sense it's a pity because by being in the stdlib it could have had a lot more visibility and maybe people would have stopped writing their own, and would have begun using it. Then maybe, if it was not perfect, people would have begun improving it, and by now we would have a solid feature available to everybody. mhm... could it be a good idea to have two versions of the stdlib? One stable, and one testing, where stuff could be thrown in without being too picky, in order to let the community decide and improve? Again, Fuzzyman, your post was just the excuse to get me started. I understand and respect your work, also because you put the remarkable effort to make it publicly available. That's my two cents, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, Michael Amrhein [EMAIL PROTECTED] wrote: Did you take a look at pyPI (http://www.python.org/pypi) ? At least you'd find another odict ... Oh, yeah. And another filesystem abstraction layer... and another xml serialization methodology... :) PyPI is actually pretty cool. If I had to vote for something going into a testing stdlib, I'd vote for PyPI. You see, that's my point, we have too many! :) stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, djw [EMAIL PROTECTED] wrote: I think, for me, this most important reason is that the stdlib version of a module doesn't always completely fill the requirements of the project being worked on. That's certainly why I wrote my own, much simpler, logging module. In this case, its obvious that the original author of the stdlib logging module had different ideas about how straightforward and simple a logging module should be. To me, this just demonstrates how difficult it is to write good library code - it has to try and be everything to everybody without becoming overly general, abstract, or bloated. That's very true. But... ...there are languages (ahem... did I hear somebody say Java? :) that make it so hard to write code, that one usually prefers using whatever is already available even if this means adopting a style that doesn't quite match his expectations. To me, it is not clear which is best: a very comfortable programmer with a longer todo list, or an unfomfortable programmer with a short todo list. So far, I've always struggled to be in the first category, but I'm amazed when I look back and see how many wheels I reinvented. But maybe it's just lack of wisdom. :) stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, Dave Brueck [EMAIL PROTECTED] wrote: shot). The cost of developing _exactly_ what you need often is (or at least *appears* to be) the same as or lower than bending to use what somebody else has already built. That's right. But as you say, this is _often_ the case, not always. One doesn't necessarily need to bend too much in order to use something that's available out there. If we're talking about simple stuff, like ordered dictionaries, file system management, ini files roundtripping, xml serialization (this one maybe is not that trivial...), I don't think you would have to come to big compromises. I myself reinvented these wheels a few times in different projects, because I wasn't happy with the way I reinvented the first time, then I eventually found some code written by someone else that was _exactly_ the same as my last attempt, my most evolved and perfect, my presciou :), if it wasn't even better. Separate paths of evolution that converged to the same solution, because the problem was simple to begin with. Under this light, it seems to me that I wasted a lot of time. If odict was in the stdlib I wouldn't have bothered writing it. And yet, this code is not available in the stdlib. Sometimes it's not even trivial to be googled for. Plus, if you think of a python beginner, what's the chance that he's gonna say: naa, this code in the library sucks. I'm gonna search google for another ini file round tripper. Whatever is available there, he's gonna use, at least in the beginning. Then he will soon figure out that it indeed sucks, and at that point there's a chance that he'll say: man... _python_ sucks! I cannot even round trip an ini file with the same module! That's why I say this lack of a centralized, officially recommended code repository maybe is hurting python. I agree that building library code is hard because it has to be both correct and simple. But, again, there's a lot of useful stuff not the library, that's simple in the start so it's just a matter of writing it correctly. If the semantics can be different, just provide a couple of alternatives, and history will judge. It would be great if there was a section in the Python manual like this: Quick and Dirty: Commonly needed tricks for real applications 1. odict 2. file system management 3. xml (de)serialization 4. ... Each section would describe the problem and list one or a few recommended implementations. All available under __testing_stdlib__. Appoint somebody as the BDFL and make the process of updating the testing stdlib democratic enough to allow for more evolution freedom than the stable stdlib. If such a quick and dirty section existed, I think it would also become a natural randevouz point for innovators. If one invented a new cool, simple and useful module, rather than just publishing it in his own public svn repository, he would feel comfortable to start a discussion on the python-testing-stdlib mailing list suggesting to include it in the quick and dirty section of the manual. The manual is the primary resource that every python programmer makes use of, expecially beginners. But it is so official that no one would ever dare suggesting to include something in it. If the Vaults of Parnassus were listed in there (maybe a bit trimmed and evaluated first ;) a beginner would have immediate access to the most common tricks that one soon faces when it comes to writing real applications. I'm talking wildly here... I'm quite aware of how simplistic I made it. Just throwing an idea. What do you think? stefano -- http://mail.python.org/mailman/listinfo/python-list
New Zope Italia Association (AZI)
We are pleased to announce the foundation of the Zope Italia Association (AZI - Associazione Zope Italia). It was created by a couple of mailing list users in the last months (since march). Main goals are to manage the Zope.IT community activities, to contribute to the diffusion and to improve the visibility of Zope, Plone and Python in Italy. Further details can be found at http://zope.it. -- Stefano Noferi Zope Italia Association -- http://mail.python.org/mailman/listinfo/python-list
