Re: [Python-Dev] mingw support?
On Sat, Aug 7, 2010 at 2:14 PM, Steve Holden wrote: > There have certainly been demonstrations that Python can be compiled > with mingw, but as far as I am aware what's missing is a developer > sufficiently motivated to integrate that build system into the > distributions and maintain it. It looks like quite a lot of activity on http://bugs.python.org/issue3871 . I find it surprising that nobody mentioned it before on this thread. Perhaps nobody who has been posting to this thread was aware of this activity. Regards, Zooko ___ 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-checkins] r83992 - in python/branches/release26-maint: Lib/distutils/command/sdist.py Lib/distutils/tests/test_sdist.py Misc/NEWS
On Aug 14, 2010, at 04:07 AM, eric.araujo wrote:
>Author: eric.araujo
>Date: Sat Aug 14 04:07:26 2010
>New Revision: 83992
>
>Log:
>Revert regression from r81256 (with release manager approval, see
>#8688)
This was a regression in 2.6.6rc1 and I'm grateful to Eric for reverting it.
While I trust he did the merge faithfully, it's still a big enough change
between rc1 and final that I encourage folks who are affected by this to test
current svn head for release26-maint and make sure it's working the way you
expect it to. This means "the same as Python 2.6.5". We've decided not to
apply any behavior changing patches to Python 2.6 so you'll just have to live
with the devil you know here, or upgrade to Python 2.7.
Please let me know before Monday if you notice any problems.
Again, thanks Eric!
-Barry
>
>
>Modified:
> python/branches/release26-maint/Lib/distutils/command/sdist.py
> python/branches/release26-maint/Lib/distutils/tests/test_sdist.py
> python/branches/release26-maint/Misc/NEWS
>
>Modified:
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>==
>---
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>(original) +++
>python/branches/release26-maint/Lib/distutils/command/sdist.py
>Sat Aug 14 04:07:26 2010 @@ -57,8 +57,7 @@
> "just regenerate the manifest and then stop "
> "(implies --force-manifest)"),
> ('force-manifest', 'f',
>- "forcibly regenerate the manifest and carry on as usual. "
>- "Deprecated: now the manifest is always regenerated."),
>+ "forcibly regenerate the manifest and carry on as usual"),
> ('formats=', None,
> "formats for source distribution (comma-separated list)"),
> ('keep-temp', 'k',
>@@ -191,34 +190,67 @@
> distribution, and put it in 'self.filelist'. This might
> involve reading the manifest template (and writing the manifest), or
> just reading the manifest, or just using the default file set -- it
> all
>-depends on the user's options.
>+depends on the user's options and the state of the filesystem.
> """
>-# new behavior:
>-# the file list is recalculated everytime because
>-# even if MANIFEST.in or setup.py are not changed
>-# the user might have added some files in the tree that
>-# need to be included.
>-#
>-# This makes --force the default and only behavior.
>-template_exists = os.path.isfile(self.template)
>-if not template_exists:
>-self.warn(("manifest template '%s' does not exist " +
>-"(using default file list)") %
>-self.template)
>-self.filelist.findall()
>-
>-if self.use_defaults:
>-self.add_defaults()
>
>+# If we have a manifest template, see if it's newer than the
>+# manifest; if so, we'll regenerate the manifest.
>+template_exists = os.path.isfile(self.template)
> if template_exists:
>-self.read_template()
>+template_newer = dep_util.newer(self.template,
>self.manifest)
>
>-if self.prune:
>-self.prune_file_list()
>+# The contents of the manifest file almost certainly depend
>on the
>+# setup script as well as the manifest template -- so if the
>setup
>+# script is newer than the manifest, we'll regenerate the
>manifest
>+# from the template. (Well, not quite: if we already have a
>+# manifest, but there's no template -- which will happen if
>the
>+# developer elects to generate a manifest some other way --
>then we
>+# can't regenerate the manifest, so we don't.)
>+self.debug_print("checking if %s newer than %s" %
>+ (self.distribution.script_name,
>self.manifest))
>+setup_newer = dep_util.newer(self.distribution.script_name,
>+ self.manifest)
>+
>+# cases:
>+# 1) no manifest, template exists: generate manifest
>+# (covered by 2a: no manifest == template newer)
>+# 2) manifest & template exist:
>+# 2a) template or setup script newer than manifest:
>+# regenerate manifest
>+# 2b) manifest newer than both:
>+# do nothing (unless --force or --manifest-only)
>+# 3) manifest exists, no template:
>+# do nothing (unless --force or --manifest-only)
>+# 4) no manifest, no template: generate w/ warning
>("defaults only") +
>+manifest_outofdate = (template_exists and
>+ (template_newer or setup_newer))
>+force_regen = self.force_manifest or self.manifest_only
>+manifest_exists = os.path.isfile(self.manifest)
>+neither_exists = (not template_exists and not manifest_exists)
>+
>+# Regene
[Python-Dev] i18n
Dear developers: I'm starting a project that aims at first to internationalize the python interpreter, so it could be localized. I want to know if this could be considered for the main trunk of python. As a second phase I intend to internationalize the language itself so it could be localized and used with kids and for programming teaching. Finally a translator to give support for international collaboration in education of youngsters. I would like to hear of anyone interested in this. Thanks in advance, Alcino Dall Igna Junior Lecturer at IC/UFAL - Brasil ___ 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] mingw support?
>> Enthought (32-bit) ships with a mingw gcc compiler configured to build >> extensions. > > Hmm. Including a gcc seems like a lot of overhead, not at least for the > need to provide sources as well. A lighter solution would be to include an importlib for the correct CRT as well as for Python, and make sure distutils link with both for mingw. For example we cannot use mingw for 64 bit extensions to Python 2.6 because libpython26.a is missing from Python and mingw-w64 don't have libmsvcr90.a. If Python shipped with both, there would not be a missing import library for the CRT and no confusion as to which CRT to link. For Python 2.5 there also was a CRT licensing issue for py2exe, but that disappaired when MS provided download links for the Visual Studio redistributables. I think this also contributed to a motivation for a plain mingw build of Python 2.5, as it would take the CRT licensing issue away from py2exe. But as of Python 2.6 this is not a problem anymore. Now it is sufficient to direct the user to Microsoft's free CRT download. Everybody might not be aware of that. Sturla ___ 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] mingw support?
Am 13.08.2010 20:45, schrieb Sturla Molden: > >> The problem really is that when people ask for MingW support, they mean >> all kinds of things, > > Usually it means they want to build C or C++ extensions, don't have Visual > Studio, don't know about the SDK compiler, and have misunderstood the CRT > problem. True. However, that should be working just fine, for many years. It just becomes a hassle every time we switch VS versions, and mingw fails to support the new CRT version. There is really nothing we can do about that, other than asking people to complain to the mingw developers. > As long at Python builds with the free Windows 7 SDK, I think it is > sufficient to that mingw is supported for extensions (and the only reasons > for selecing mingw over Microsoft C/C++ on windows are Fortran and C99 -- > the Windows SDK compiler is a free download as well.) People keep disagreeing with that judgement, and keep contributing patches that supposed make Python itself build with mingw. > Enthought (32-bit) ships with a mingw gcc compiler configured to build > extensions. Hmm. Including a gcc seems like a lot of overhead, not at least for the need to provide sources as well. 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] Fixing #7175: a standard location for Python config files
On 13/08/2010 10:02 PM, Michael Foord wrote:
On 13/08/2010 06:39, Stephen J. Turnbull wrote:
Michael Foord writes:
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)
But what does "~" mean on Windows?
There is a "user directory" in Windows directly analagous to ~, and this
is the path returned by os.path.expanduser('~') in Python:
Well, see my post early on in the thread about the
various senses of "user directory" under Windows.
The addition of expanduser to include Windows caused
a long debate at the time. (ISTR)
I'm not really all that bothered for this purpose.
There's something to be said for all the suggestions
so far. However, as I've said elsewhere, I'm more
concerned that whatever we end up choosing for
location(s) be clearly documented as such.
TJG
___
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] Fixing #7175: a standard location for Python config files
On 13/08/2010 06:39, Stephen J. Turnbull wrote:
Michael Foord writes:
> How is ~/python not memorable or consistent? (And cross-platform
> memorability and consistency is valuable too.)
But what does "~" mean on Windows?
There is a "user directory" in Windows directly analagous to ~, and this
is the path returned by os.path.expanduser('~') in Python:
>>> import os
>>> os.path.expanduser('~')
'C:\\Users\\michael'
(Windows 7)
Inside of Python you can have a
consistent definition, but that doesn't help people whose installer
gets mixed signals so Python itself is in the wrong place, or who are
using external tools (uninstaller, editor, application, etc) that work
on or with Python.
I'm not arguing for use of AppData, but at least it's easy to explain,
and easy to implement, for consistency.
Likewise with the user directory (IMO) - in fact to explain where
AppData is to a Windows user you first explain about the user directory
(AppData is under the user directory).
Personally I would like to see the defaults being:
Linux: ~/.pythonx.y
Mac OS X: ~/.pythonx.y with a fallback of ~/Library/Preferences/.pythonx.y
Windows: ~/pythonx.y perhaps with a backup of AppData/pythonx.y
For both Windows and Mac OS X I would be happy with the fallback /
primary to be the other way round - it doesn't *really* matter. The API
for getting the user config direction should always return a list I
guess if we have fallbacks.
Someone else in this thread (Adal Chiriliuc) expressed a preferences for
the documents folder on Windows over the home directory. This would be
fine as well (with AppData still as a fallback). This is used by other
native windows applications. (In earlier versions of Windows the
documents folder was explicitly called "Documents and Settings".)
We should use pythonx.y rather than just python because (for example)
you will typically have different packages installed when you have
multiple versions of Python, and in unittest would then want / need
different plugins enabled and configured in the unittest config files
for each of the versions of Python.
I've added this text to the issue and Tarek - as bdfl for distutils2
should just make a decision (and the rest of us will have to live with
it). :-)
> Another issue is discoverability. Many users won't know about these
> config files unless they *see* them.
OK, maybe AppData's out.
> In fact for Windows the *correct* thing to do is probably to use
> the registry and then provide a graphical tool for editing the
> values. If you're arguing for consistency why not argue for this?
Sounds reasonable to me. Except Python's standard GUI is probably not
up to Windows standards of beauty
Heh, I was actually being slightly sarcastic - just pointing out that if
we are going to argue that we should do the "correct" thing for the
platform that means the registry on Windows and plists on Mac OS X, with
GUI apps to control them. That is an unnecessary burden for the standard
library and actively makes them harder for developers to maintain
themselves.
All the best,
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
___
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] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 3:21 PM, John Arbash Meinel wrote: > I don't know what the specific issue is here, but adding entries to > sys.path makes startup time *significantly* slower. > > I happen to use easy_install since Windows doesn't have its own package > manager. Unfortunately the default of creating a new directory and > adding it to easy_install.pth is actually pretty terrible. Adding sys.path entries on Linux isn't free either. Fortunately, this isn't about adding anything to sys.path. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Python 2.6.6 status
Hi folks, I'm liking where we're at for Python 2.6.6. We have no release blocker issues open, and the buildbots look about as green as they get. I've accounted for all the commits since 2.6.6rc1 and I think barring any last minute issues, that we're on schedule for 2.6.6 final for this Monday, August 16. Please, no commits to release26-maint without checking with me first (svnmerge blocks are okay). I plan to tag the release at approximately 2200 UTC Monday so that Martin can build the Windows binaries first thing on Tuesday and I can announce the release Tuesday afternoon EST. I'll be hanging out on #python-dev as much as possible over the weekend in case anything crops up. Thanks to everybody who has helped get 2.6.6 to such an awesome state. -Barry signature.asc Description: 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] Fixing #7175: a standard location for Python config files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ... > * that said, Windows seems much slower than Linux on equivalent >hardware, perhaps attempting to open files is intrinsically more >expensive there? Certainly it's not safe to assume conclusions drawn >on Linux will apply equally well on Windows, or vice versa. I don't know what the specific issue is here, but adding entries to sys.path makes startup time *significantly* slower. I happen to use easy_install since Windows doesn't have its own package manager. Unfortunately the default of creating a new directory and adding it to easy_install.pth is actually pretty terrible. On my system, 'len(sys.path)' is 72 entries long. 62 of that is from easy-install. A huge amount of that is all the zope and lazr. dependencies that are needed by launchpadlib (not required for bzr itself.) With a fully hot cache, and running the minimal bzr command: time bzr rocks --no-plugins real 0m0.395s vs real 0m0.195s So about 400ms to startup versus 200ms if I use the packaged version of bzr (which has a very small search path). John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlm0kACgkQJdeBCYSNAAMSEgCfW24XNG3h20UkFdEODNMob6uR nisAoLes/usoHd1YRDIkzxfIJohPjSer =YO9b -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] mingw support?
"Cesare Di Mauro": > I like to use Windows because it's a comfortable and productive > environment, > certainly not because someone forced me to use it. > > Also, I have limited time, so I want to spend it the better I can, > focusing > on solving real problems. Setup, Next, Next, Finish, and I want it working > without thinking about anything else. [...] > Give users a better choice, and I don't see logical reasons because > they'll > not change their mind. I use Windows too, even though I am a scientist and most people seem to prefer Linux for scientific computing. I do like to just click on the installer from Enthought and forget about building all the binaries an libraries myself. Maybe I am just lazy... But likewise, I think that most Windows users don't care which C compiler was used to build Python. Nor do we/they care which compiler was used to build any other third-party software, as long as the MSI installers works and the binaries are void of malware. Also note that there are non-standard things on Windows that mingw does not support properly, such as COM and structured exceptions. Extensions like pywin32 depend on Microsoft C/C++ for that reason. So for Windows I think it is sufficient to support mingw for extension libraries. The annoying part is the CRT DLL hell, which is the fault of Microsoft. An easy fix would be a Python/mingw bundle, or a correctly configured mingw compiler from python.org. Or Python devs could consider not using Microsoft's CRT at all on Windows, and replacing it with a custom CRT or plain Windows API calls. Sturla ___ 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] mingw support?
> The problem really is that when people ask for MingW support, they mean > all kinds of things, Usually it means they want to build C or C++ extensions, don't have Visual Studio, don't know about the SDK compiler, and have misunderstood the CRT problem. As long at Python builds with the free Windows 7 SDK, I think it is sufficient to that mingw is supported for extensions (and the only reasons for selecing mingw over Microsoft C/C++ on windows are Fortran and C99 -- the Windows SDK compiler is a free download as well.) Enthought (32-bit) ships with a mingw gcc compiler configured to build extensions. That might be something to consider for Python on Windows. It will prevent accidental linking with wrong libraries (particularly the CRT). Sturla ___ 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] Fixing #7175: a standard location for Python config files
On Fri, 13 Aug 2010 11:57:57 -0400 Barry Warsaw wrote: > On Aug 12, 2010, at 09:10 AM, Fred Drake wrote: > > >Perhaps user configuration belongs in ~/.local/, or ~/.local/python/ > >(with attendant Windows & Mac OS noises); I don't really care where it > >lands, because right now we just have a mess. Getting it "right" with > >respect to Window's "roaming" notion and how people expect to work > >with it is... unlikely. Picking a place is better than not, so we > >know where to find things. But that's all it buys us. > > I've missed most of this discussion while on vacation, but if ~/.local is > supposed to mirror /usr/local, then wouldn't a logical place for per-user > configuration files be ~/.local/etc/whatever.cfg? I think this has already been debated, -1 on it. Antoine. ___ 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] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 11:57 AM, Barry Warsaw wrote: > I've missed most of this discussion while on vacation, but if ~/.local is > supposed to mirror /usr/local, then wouldn't a logical place for per-user > configuration files be ~/.local/etc/whatever.cfg? Maybe it is; I'd hope so. The fd.o spec that describes ~/.local/share/ doesn't say anything *else* about ~/.local/, though. So our expansion of ~/.local/ is very much our own. My own ~/.local/ contains a bunch of gnomish desktop stuff in share/ and Python stuff in lib/, and that's it. I'd be as happy as I'm going to be with configs in ~~/.local/etc/. (Still going to be a grouchy old fart.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Proposed tweaks to functools.wraps
True. It is tricky. However, not as tricky as finding the decorated function after the fact (unless I am missing something). But maybe that is a fringe need (finding the original function). -eric -Original Message- From: Nick Coghlan [mailto:ncogh...@gmail.com] Sent: Friday, August 13, 2010 10:07 AM To: Eric Snow Cc: python-dev@python.org Subject: Re: [Python-Dev] Proposed tweaks to functools.wraps On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote: > Actually, what is the problem with having all decorators add a __decorated__ > to the function that ultimately gets returned, pointing to the function they > decorated? I guess I never saw that discussion. Perhaps set it to None when > the decorator is the same as the decorated (no wrapping involved). The > alternative is sifting through closures, trying to figure out which is the > decorated function. Finding the original decorated function has been a real > pain, particularly when a function has more than one closure cell. Because decorators don't always return simple wrapper functions - sometimes they return the original function and sometimes they completely replace the original function with something else entirely (which may not be callable, or even mutable). We refused the temptation to try to guess when it was appropriate to add the referring attribute. functools.update_wrapper and functools.wraps are explicit though, so it's easy to add the attribute there, we just hadn't thought of doing it before now. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. ___ 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] Fixing #7175: a standard location for Python config files
On Aug 12, 2010, at 09:10 AM, Fred Drake wrote: >Perhaps user configuration belongs in ~/.local/, or ~/.local/python/ >(with attendant Windows & Mac OS noises); I don't really care where it >lands, because right now we just have a mess. Getting it "right" with >respect to Window's "roaming" notion and how people expect to work >with it is... unlikely. Picking a place is better than not, so we >know where to find things. But that's all it buys us. I've missed most of this discussion while on vacation, but if ~/.local is supposed to mirror /usr/local, then wouldn't a logical place for per-user configuration files be ~/.local/etc/whatever.cfg? -Barry signature.asc Description: 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-08-06 - 2010-08-13) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues stats: open2645 (+42) closed 18724 (+83) total 21369 (+51) Open issues with patches: 1107 Issues opened (42) == #3402: test_nis is hanging on Solaris http://bugs.python.org/issue3402 reopened by benjamin.peterson #5416: str.replace does strange things when given a negative count http://bugs.python.org/issue5416 reopened by rhettinger #5504: ctypes should work with systems where mmap can't be PROT_WRITE http://bugs.python.org/issue5504 reopened by pitrou #7467: The zipfile module does not check files' CRCs, including in Zi http://bugs.python.org/issue7467 reopened by pitrou #8688: distutils sdist is too laze w.r.t. recalculating MANIFEST http://bugs.python.org/issue8688 reopened by ronaldoussoren #9323: trace.py bug with the main file being traced http://bugs.python.org/issue9323 reopened by belopolsky #9396: Standardise (and publish?) cache handling in standard library http://bugs.python.org/issue9396 reopened by rhettinger #9424: Disable unittest.TestCase.assertEquals and assert_ during a re http://bugs.python.org/issue9424 reopened by michael.foord #9538: Replace confusing pseudoname 'object' in special methods secti http://bugs.python.org/issue9538 opened by terry.reedy #9539: python-2.6.4: test failure in test_distutils due to linking to http://bugs.python.org/issue9539 opened by valeo #9542: Create PyUnicode_FSDecoder() function http://bugs.python.org/issue9542 opened by haypo #9544: xdrlib.Packer().pack_fstring throws a TypeError when called wi http://bugs.python.org/issue9544 opened by arnoldp #9545: Adding _collections to static build http://bugs.python.org/issue9545 opened by orsenthil #9548: locale can be imported at startup but relies on too many libra http://bugs.python.org/issue9548 opened by pitrou #9549: Remove sys.setdefaultencoding() http://bugs.python.org/issue9549 opened by pitrou #9552: ssl build under Windows always rebuilds OpenSSL http://bugs.python.org/issue9552 opened by pitrou #9553: test_argparse.py: 80 failures if COLUMNS env var set to a valu http://bugs.python.org/issue9553 opened by denversc #9554: test_argparse.py: use new unittest features http://bugs.python.org/issue9554 opened by denversc #9556: Specifying the time a TimedRotatingFileHandler rotates http://bugs.python.org/issue9556 opened by ronaldoussoren #9557: test_mailbox failure under a Windows VM http://bugs.python.org/issue9557 opened by pitrou #9558: build_ext fails on VS8.0 http://bugs.python.org/issue9558 opened by ocean-city #9559: mailbox.mbox creates new file when adding message to mbox http://bugs.python.org/issue9559 opened by chrisisbd #9560: platform.py: use -b option for file command in _syscmd_file() http://bugs.python.org/issue9560 opened by haypo #9561: distutils: set encoding to utf-8 for input and output files http://bugs.python.org/issue9561 opened by haypo #9562: Slightly misleading wording in documentation of dict.update http://bugs.python.org/issue9562 opened by MLModel #9566: Compilation warnings under x64 Windows http://bugs.python.org/issue9566 opened by pitrou #9567: Add attribute pointing to wrapped function in functools.update http://bugs.python.org/issue9567 opened by eric.araujo #9568: test_urllib2_localnet fails on OS X 10.3 http://bugs.python.org/issue9568 opened by ned.deily #9569: Add tests for posix.mknod() and posix.mkfifo() http://bugs.python.org/issue9569 opened by baikie #9571: argparse: Allow the use of -- to break out of nargs and into s http://bugs.python.org/issue9571 opened by elsdoerfer #9572: IOError in test_multiprocessing http://bugs.python.org/issue9572 opened by flox #9573: importing a module that executes fork() raises RuntimeError http://bugs.python.org/issue9573 opened by Alex.Roitman #9574: complex does not parse strings containing decimals http://bugs.python.org/issue9574 opened by jdwhitley #9576: logging.addLevelName in file-based configurations http://bugs.python.org/issue9576 opened by tarek #9579: In 3.x, os.confstr() returns garbage if value is longer than 2 http://bugs.python.org/issue9579 opened by baikie #9580: os.confstr() doesn't decode result according to PEP 383 http://bugs.python.org/issue9580 opened by baikie #9581: PosixGroupsTester fails as root http://bugs.python.org/issue9581 opened by pitrou #9582: documentation line needs rewording http://bugs.python.org/issue9582 opened by mohrr #9583: PYTHONOPTIMIZE = 0 is not honored http://bugs.python.org/issue9583 opened by bukzor #9584: Allow curly braces in fnmatch http://bugs.python.org/issue9584 opened by bochecha #9586: "warning: comparison between pointer and integer" in multiproc http://bugs.python.org/issue9586 opened by mark.dickinson #9587: unittest.assertRaises() return
Re: [Python-Dev] Proposed tweaks to functools.wraps
On Sat, Aug 14, 2010 at 1:01 AM, Eric Snow wrote: > Actually, what is the problem with having all decorators add a __decorated__ > to the function that ultimately gets returned, pointing to the function they > decorated? I guess I never saw that discussion. Perhaps set it to None when > the decorator is the same as the decorated (no wrapping involved). The > alternative is sifting through closures, trying to figure out which is the > decorated function. Finding the original decorated function has been a real > pain, particularly when a function has more than one closure cell. Because decorators don't always return simple wrapper functions - sometimes they return the original function and sometimes they completely replace the original function with something else entirely (which may not be callable, or even mutable). We refused the temptation to try to guess when it was appropriate to add the referring attribute. functools.update_wrapper and functools.wraps are explicit though, so it's easy to add the attribute there, we just hadn't thought of doing it before now. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Proposed tweaks to functools.wraps
Actually, what is the problem with having all decorators add a __decorated__ to the function that ultimately gets returned, pointing to the function they decorated? I guess I never saw that discussion. Perhaps set it to None when the decorator is the same as the decorated (no wrapping involved). The alternative is sifting through closures, trying to figure out which is the decorated function. Finding the original decorated function has been a real pain, particularly when a function has more than one closure cell. -eric -Original Message- From: python-dev-bounces+esnow=verio@python.org [mailto:python-dev-bounces+esnow=verio@python.org] On Behalf Of Nick Coghlan Sent: Tuesday, August 10, 2010 8:31 PM To: python-dev@python.org Subject: [Python-Dev] Proposed tweaks to functools.wraps Based on a pair of tracker issues (#3445 and #9396) I'm considering a couple of adjustments to functools.wraps for 3.2. The first (#3445) is a request from ages ago to make update_wrapper more forgiving when it encounters a missing attribute. Instead of throwing AttributeError (as it does now), it would just skip the missing attribute. This would allow wraps to be used with other callables that don't fully mimic the function API. I was initially opposed to the idea, but over time I've come to think this is a case where practicality beats purity (since that really sums up functools.wraps in general - it is already the case that the copied info isn't quite right for the decorated function, but it's still better than using the wrapper function's own metadata). The second (#9396) came up in the context of the new cache decorators added to functools, and allowing applications to choose their own caching strategies. I suggested exposing the original (uncached) function, and Raymond suggested that the easiest way to enable that would be for functools.update_wrapper to add a new attribute that provides a reference to the original function. Some time back, we considered doing this automatically as an integral part of decoration, but decided that wasn't appropriate. However, building it into the explicit wrapping functions makes sense to me. To avoid namespace conflicts, I plan to use "__wraps__" as the name for the reference to the original function. Thoughts? Concerns? Better ideas? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/esnow%40verio.net This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. ___ 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] Fixing #7175: a standard location for Python config files
On Thu, Aug 12, 2010 at 11:48 PM, Nick Coghlan wrote: > 2010/8/12 Éric Araujo : >>> Choosing an arbitrary location we think is good on every system is fine >>> and non risky I think, as long as Python let the various distribution >>> change those paths though configuration. >> >> Don’t you have a bootstrapping problem? How do you know where to look at >> the sysconfig file that tells where to look at config files? Not if located in a place known/owned by the interpreter whatever the layout is. > > Personally, I'm not clear on what a separate syconfig.cfg file offers > over clearly separating the directory configuration settings and > continuing to have distributions patch sysconfig.py directly. The > bootstrapping problem (which would encourage classifying synconfig.cfg > as source code and placing it alongside syscongig.py) is a major part > of that point of view. Sure, sysconfig.cfg would be part of the distribution, and this is not really different from code from our core point of view. But it seems more appealing to give the ability to change installation locations through configuration rather than by patching the code, because the latter also implies that Python behaves differently when patched, and add more maintenance burden for everybody. For us for instance, it would be more comfortable to keep most content in sysconfig private, so we can change them at ease without breaking distributions that patches it. I would hate to have to do a deprecation cycle if we change the way sysconfig internally works. A documented cfg file feels just more standard-ish to me for this. Regards. Tarek -- Tarek Ziadé | http://ziade.org ___ 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] mingw support?
> The question is "who will support those folks?" I don't see any > reason why you or Martin should support MSYS/mingw if you don't want > to, but please don't put down the folks who ask for it. Just say "no, > it's not worth it". Or maybe, "if you want to do the work, I might > contribute some reviews." Or whatever. The problem really is that when people ask for MingW support, they mean all kinds of things, and they "can't agree" among themselves what that is. Some want cross-compiling (i.e. compile using mingw on Linux). Some want autoconf for mingw with msys. Some want autoconf for mingw with cygwin. Some want to replace the build system entirely, and have the new build system support mingw (and claim that you otherwise can't get "good" mingw support). It's not that I'm objecting mingw support per se, but have my issues with each individual patch proposed so far. As for reviewing: people proposing mingw patches somehow always arrive at very large patches. Reviewing them is very difficult also. 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] mingw support?
2010/8/13 Greg Ewing > Cesare Di Mauro wrote: > > You must suggest at least an equivalent "free" alternative to make the >> switch convenient. >> >> Otherwise we are talking about philosophy or religion, and nobody will >> change his ideas. >> > > I think the point is that *because* people don't want to change > their ideas, it would be good to have a mingw-based alternative. > Otherwise everyone is forced to convert to the Windows religion. > > -- > Greg I like to use Windows because it's a comfortable and productive environment, certainly not because someone forced me to use it. Also, I have limited time, so I want to spend it the better I can, focusing on solving real problems. Setup, Next, Next, Finish, and I want it working without thinking about anything else. It's a philosophy similar to Python: you don't need to know if the platform where it's running is 32 or 64 bits, little or big endian, the operating system, and so on. Just launch it and start typing code: it'll work. It can be also a matter of taste. I like graphical environments since the old Amiga days. If I need a shell, I greatly prefer Python. Anyway, for Windows there's cygwin too, and Python works. But after some months I replaced it with native Windows tools (with VisualStudio on top): I work much, much better this way. If someone is interested in a mingw port, he should consider about having decent alternatives to what a Windows user can found on his platform, otherwise it'll be just pure exercise or a faith matter, since nobody will use it concretely on a daily work. Give users a better choice, and I don't see logical reasons because they'll not change their mind. My 2 cents. Cesare ___ 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
