Re: [Python-Dev] Third preview of 3.4.0rc2 is up
2014-02-21 11:06 Larry Hastings napisał(a):
> On 02/21/2014 01:30 AM, Ned Deily wrote:
> > In article <53070a8a.8080...@hastings.org>,
> > Larry Hastings wrote:
> >> As before you'll find the results here:
> >>
> >> http://midwinter.com/~larry/3.4.status/
> > Status says that:
> >
> > eef7899ea7ab Doc: do not rely on checked-out Sphinx toolchain from
> > svn.python.org anymore
> >
> > is unmerged, which is what Georg and I agreed upon in Issue20661. Yet,
> > in the current python.3.4.2014.02.21.00.07.42.tgz tarball, that change
> > appears to be present and, as such, causes installer builds to fail.
> >
>
> Whoopsie! My local branch is actually correct. But! I effectively did
> this in my automation:
>
> % hg clone 3.4 python-{time}
> % cd python-{time}
> % rm -rf .hg* .bzr* .git*
> % cd ..
> % tar cvfz python-{time}.tgz python-{time}
>
> Can you spot the error? That's right: when you clone, the clone always
> starts out in "default". So all the tarballs I've published so far have
> been wrong. ARGH. Sorry!
>
> I've added a "hg branch 3.4" in a judicious spot in my automation.
You can use 'hg clone -u 3.4 3.4 python-{time}'.
$ hg clone --help
...
To check out a particular version, use -u/--update, or -U/--noupdate to
create a clone with no working directory.
...
-u --updaterev REV revision, tag or branch to check out
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library
2019-05-21 00:06 UTC+02:00, Christian Heimes wrote: > On 20/05/2019 23.27, Antoine Pitrou wrote: >> Removing the crypt module would remove support for system-standard >> password files. I don't understand the rationale. > > Applications *must* not access system-standard password files directly. On > any sanely and securely configured systems, application cannot even access > system password files like /etc/shadow. Access restrictions and system > security policies will prevent read access. Also applications cannot assume > that users are present in any user file. They may come from LDAP, SSSD, > ActiveDirectory, or other sources. > > The correct way to interact with system users is to use the proper APIs, > that are NSS (name service switch) and PAM (pluggable authentication > modules). NSS looks up and enumerate users and groups. PAM performs password > validation and much, much, much more. The pwd and grp modules use the > correct APIs to interact with NSS. If you need to check or change passwords, > you must go through PAM. It is possible to have a modern Linux desktop system with PAM not installed at all, and therefore not used. Examples of packages in Gentoo Linux which have OPTIONAL dependency on PAM: shadow, sudo, openssh, libcap, systemd, util-linux, screen, cronie, polkit, cups, sddm, kscreenlocker, xscreensaver (So a KDE Plasma desktop environment and its direct and indirect dependencies can be installed without PAM.) The suggested substitutes for spwd module, i.e. python-pam and simpleplam, look like they would not work on a PAM-free system. -- Arfrever Frehtes Taifersar Arahesis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent
2022-04-09 04:24 UTC, Terry Reedy は書いた: > Perhaps something intentionally vague like > > "Manual deletion of entries from sys.modules may invalidate statements > above, even after re-imports." > > or > > "Manual deletion of entries from sys.modules may result in surprising > behavior, even after re-imports." Not only deletion, but also random assignments: >>> import sys >>> import collections.abc >>> sys.modules['collections'] = 1 >>> import collections.abc >>> collections.abc Traceback (most recent call last): File "", line 1, in AttributeError: 'int' object has no attribute 'abc' ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IRXLI6XANNQTOGSBQGOFX25UJD6J4SGJ/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Dates in python-dev
2009-04-24 18:29:29 MRAB napisał(a): > Hi, > > I've recently subscribed to this list and received my first "Summary of > Python tracker Issues". What I find annoying are the dates, for example: > > ACTIVITY SUMMARY (04/17/09 - 04/24/09) > > 3 x double-digits (have we learned nothing from Y2K? :-)) with the > _middle_ ones changing fastest! > > I know it's the US standard, but Python is global. Could we have an > 'international' style instead, say, year-month-day: > > ACTIVITY SUMMARY (2009-04-17 - 2009-04-24) +1. ISO 8601 should be mandatory. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] Oddity PEP 0 key
2009-05-02 07:34:15 Stephen J. Turnbull napisał(a): > Barry Warsaw writes: > > On May 1, 2009, at 5:55 PM, Michael Foord wrote: > > > > > P for Proposal (to replace Active Proposal)? Every active PEP is a > > > proposal... > > > > +1 > > > > Maybe even s/Active/Proposed/g ? > > Shouldn't that be > > s/Active/Proposed/ No. From `info sed 'sed Programs' 'The "s" Command'`: > The `s' Command > === > >The syntax of the `s' (as in substitute) command is > `s/REGEXP/REPLACEMENT/FLAGS'. The `/' characters may be uniformly > replaced by any other single character within any given `s' command. > The `/' character (or whatever other character is used in its stead) > can appear in the REGEXP or REPLACEMENT only if it is preceded by a `\' > character. > ... >The `s' command can be followed by zero or more of the following > FLAGS: > > `g' > Apply the replacement to _all_ matches to the REGEXP, not just the > first. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
2009-11-03 18:35:10 Guido van Rossum napisał(a): > I've checked draft (!) PEP 3003, "Python Language Moratorium", into > SVN. As authors I've listed Jesse, Brett and myself. > > On python-ideas the moratorium idea got fairly positive responses > (more positive than I'd expected, in fact) but I'm bracing myself for > fierce discussion here on python-dev. It's important to me that if if > this is accepted it is a "rough consensus" decision (working code we > already have plenty of :-), not something enforced by a vocal minority > or an influential individual such as myself. If there's too much > opposition I'll withdraw the PEP so as not to waste everybody's time > with a fruitless discussion. > > The PEP tries to spell out some gray areas but I'm sure there will be > others; that's life. Do note that the PEP proposes to be *retroactive* > back to the 3.1 release, i.e. the "frozen" version of the language is > the state in which it was released as 3.1. Does moratorium allow to add support for e.g. 'from __future__ import yield_from' in Python 3.2? -- Arfrever Frehtes Taifersar Arahesis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7/3.2 release schedule
2009-11-02 21:00 Benjamin Peterson napisał(a): > I've updated PEP 373 with my proposed release schedule: > > - 2.7/3.2 alpha 1 2009-12-05 > - 2.7/3.2 alpha 2 2010-01-09 > - 2.7/3.2 alpha 3 2010-02-06 > - 2.7/3.2 alpha 4 2010-03-06 > - 2.7/3.2 beta 1 2010-04-03 > - 2.7/3.2 beta 2 2010-05-01 > - 2.7/3.2 rc1 2010-05-29 > - 2.7/3.2 rc2 2010-06-12 > - 2.7/3.2 final 2010-06-26 PEP 3003 states that Python 3.2 will be released 18-24 months after Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so theoretically Python 3.2 should be released not before 2010-12-19 [2]. [1] http://python.org/download/releases/3.1/ [2] datetime.date(2009, 6, 27) + datetime.timedelta(18 * 30) -- Arfrever Frehtes Taifersar Arahesis ___ 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] buildtime vs runtime in Distutils
2009-11-15 02:21:41 Tarek Ziadé napisał(a): > Hello, > > http://bugs.python.org/issue4359 reminds me that Distutils reads build > files like Makefile or pyconfig.h to get some environment > variables through the sysconfig module at *runtime*. > > This cannot work on all platforms, when our Makefile is not shipped > with python but python-devel. (like Fedora) > > Since I am already working on the refactoring of this > distutils/sysconfig module, so it lands in a stdlib module together > with some > elements from site.py (see a previous mail on the topic, and my > tarek_sysconfig branch - work in progress), > > I was wondering if we couldn't make this module a template, and inject > at its beginning new values extracted from Makefile and pyconfig.h. > > This could happen when "configure" is called, It seems to be a good idea. You should create a .py.in file and use AC_SUBST and AC_CONFIG_FILES macros in configure.in. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
2009-12-28 02:17:22 Ben Finney napisał(a): > Tarek Ziadé writes: > > > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > > wrote: > > > Also, "Requires-Python: 3" would include all 3.X versions, correct? > > > > Correct, because, "Requires-Python: 3" is equivalent to > > "Requires-Python: ~= 3" which is equivalent to "Requires-Python: > > 3.x.x" > > This is totally counter to conventional comparisons, and is an excellent > example of why the equivalence of ‘3’ to ‘>=3, <4’ is a bad idea. > > Instead, the default should be ‘==’. That is, ‘Requires-Python: 3’ > should be equivalent to ‘Requires-Python: ==3’; and only “3” or “3.0” or > “3.0.0” etc. will match. I maintain that is what most people will expect > on seeing that syntax. > > If a less strict range is desired, the existing comparison operators > ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: ‘Requires-Python: >=3, <4’. IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] Support the /usr/bin/python2 symlink upstream
2011-03-01 22:50:34 Kerrick Staley napisał(a): > On Tue, Mar 1, 2011 at 3:26 PM, Eric Smith wrote: > > On 3/1/2011 4:19 PM, Kerrick Staley wrote: > >> Hello, > >> There is a need for the default Python2 install to place a symlink at > >> /usr/bin/python2 that points to /usr/bin/python, or for the > >> documentation to recommend that packagers ensure that python2 is > >> defined. Also, all documentation should be changed to recommend that > >> "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. > >> This is needed because some distributions (Arch Linux, in particular), > >> point /usr/bin/python to /usr/bin/python3, while others (including > >> Slackware, Debian, and the BSDs, probably more) do not even define the > >> python2 command. This means that a script has no way of achieving > >> cross-platform compatibility. The point at which many distributions > >> begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for > >> the next couple of years, it would be best to use a python2 or python3 > >> shebang in all scripts, making no assumptions about plain python, which > >> should only be invoked interactively. This email from about 3 years ago > >> seems relevant: : > >> http://mail.python.org/pipermail/python-3000/2008-March/012421.html > >> Again, this issue needs to be addressed by the Python developers > >> themselves so that different *nix distributions will handle it > >> consistently, allowing Python scripts to continue to be cross-platform. > >> > >> > > I believe we agreed at the language summit last year (or maybe even the > > year before) that "python" would always be python2.x, and "python3" would be > > python3.x. > > > > And by "always" we indeed meant forever. To do otherwise would break > > scripts even many, many years from now. > > I understand, but is it at least possible to officially recommend that > python, python2, and python3 all exist, that distributions point python to > python2, and that scripts specify which of python2 and python3 they are > using? This would create a redundant system that doesn't avoids problems > even if distributions do decide to ignore the second point. If not, can > someone point me to official documentation that recommends that python > always invoke Python2, so that I can take the case up with the Arch > developers? Gentoo most likely will switch /usr/bin/python to Python 3 in this year. Majority of Python-2-only packages have been already prepared to use /usr/bin/python2 or /usr/bin/python2.X. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
2011-03-07 10:33:17 Martin v. Löwis napisał(a): > Am 07.03.2011 10:14, schrieb Nick Coghlan: > > On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel > > wrote: > >> > >> Especially since, AIUI, deprecations are suppressed by default now. > > > > True, but developers are expected to run their tests with them enabled. > > I think everything here is as it should be. IMHO cobject.h should have been declaring deprecated functions with Py_DEPRECATED, which would cause build-time deprecation warnings. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] API deprecations in Python 3, from a Python 2 perspective
2011-03-19 03:42:54 Nick Coghlan napisał(a): > 4. Anyone testing C extensions against the 3.2 alpha and beta releases > must have either not used the PyCObject API in the first place, or > else had already ported their code to use the PyCapsule API as > necessary. Gentoo Python maintainer had noticed build failures related to PyCObject, but he wasn't treating these problems as a bug in Python. https://bugs.gentoo.org/buglist.cgi?short_desc=Python%203.2%20PyCObject;short_desc_type=allwordssubstr;order=bug_id -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] warn_unused_result warnings
2011-04-01 03:23:10 Victor Stinner napisał(a): > Le 01/04/2011 01:11, Benjamin Peterson a écrit : > > I'm rather sick of seeing this warnings on all compiles, so I propose > > we enable the -Wno-unused-results option. I judge that most of the > > cases where this occurs are error reporting functions, where not much > > with return code can be done. > Can't we try to fix the warnings instead of turning them off? Or is it > possible to only turn off these warnings on a specific function? http://gcc.gnu.org/gcc-4.6/changes.html "Support for selectively enabling and disabling warnings via #pragma GCC diagnostic has been added." -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] [PATCH] Respect LDFLAGS
I'm attaching the patch which fixes respecting LDFLAGS when building libpython$(VERSION).so. -- Arfrever Frehtes Taifersar Arahesis Index: Makefile.pre.in === --- Makefile.pre.in (revision 66032) +++ Makefile.pre.in (working copy) @@ -412,10 +412,10 @@ libpython$(VERSION).so: $(LIBRARY_OBJS) if test $(INSTSONAME) != $(LDLIBRARY); then \ - $(LDSHARED) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ + $(LDSHARED) $(LDFLAGS) -Wl,-h$(INSTSONAME) -o $(INSTSONAME) $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ $(LN) -f $(INSTSONAME) $@; \ else\ - $(LDSHARED) -o $@ $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ + $(LDSHARED) $(LDFLAGS) -o $@ $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM); \ fi libpython$(VERSION).sl: $(LIBRARY_OBJS) signature.asc Description: This is a digitally signed message part. ___ 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] RELEASED Python 2.6rc1
2008-09-17 15:46:19 Barry Warsaw napisał(a): > On Sep 17, 2008, at 5:59 AM, Jesus Cea wrote: > > > > Barry Warsaw wrote: > >> On behalf of the Python development team and the Python community, > >> I am > >> happy to announce the first release candidate for Python 2.6. > > > > In http://www.python.org/download/releases/2.6/ , release date for > > 2.6rc1 is 20-Aug-2008. That is not right. > > Fixed, thanks. Release date for 2.6rc1 should be 12-Sep-2008 instead of 17-Sep-2008. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] My patches
2008-10-30 16:04 A.M. Kuchling <[EMAIL PROTECTED]> napisał(a): > On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: >> One of the reasons why I'm very keen on us moving to a distributed version >> control system is to help break the logjam on core developers. True, your >> code will still not be able to land in the "official" branch without core >> developer intervention, but you will be able to share your code, fixes, >> branches with everyone in a much more live way than patches in a tracker. > > I don't see how a DVCS will fix anything. The bottleneck is in > assessing patches for inclusion in the master tree; not enough people > are doing that. We'd just end up with lots of proposed branches > waiting to be merged, instead of patches to be applied. > > (What a DVCS might enable is making it easier to do larger > experiments, like the recent Vmgen work, and publish them in a form > that people can download. We could create SVN branches now, but that > means people would then have commit access to all of the Python > source.) SVN supports path-based authorization. http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.6.1 documentation not available for download
Python 2.6.1 documentation currently isn't available for download at: http://docs.python.org/ftp/python/doc/ Additionally please include version numbers in documentation archives (e.g. python-docs-html-2.6.1.tar.bz2). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6.1 documentation not available for download
2008-12-20 23:46:15 Benjamin Peterson napisał(a): > On Sat, Dec 20, 2008 at 4:28 PM, Arfrever Frehtes Taifersar Arahesis > wrote: > > Python 2.6.1 documentation currently isn't available for download at: > > http://docs.python.org/ftp/python/doc/ > > It is avaiable here, though: > > http://www.python.org/ftp/python/doc/current/ I need documentation created from the 'r261' tag, not from the HEAD of the 'release26-maint' branch. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] I would like an svn account
2009-01-03 18:10:27 Martin v. Löwis napisał(a): > > 1. I think that a patch can not e.g. capture a moved, renamed or deleted > > file. > > Correct. However, this rarely happened. Contributors are not supposed > rename files, and they can indicate deletions and additions in plain > English (I typically request a tarfile for additions). > > > Further, it can not handle e.g. things like the executable bit or similar > > things that SVN otherwise does manage. That is what makes a patch only > > partially suitable. > > Probably correct; this isn't a problem in practice, either. In fact, it > is better if properties come from the subversion installation of the > committer, rather than from the contributor, as the committer is > supposed to have his autoprops set correctly. > > I do think that "svn diff" will record property changes, and that may > include svn:executable. I don't know which patch tool would interpret > them, though. Subversion 1.7 will probably contain 'svn patch' subcommand, which will be able to apply patches which change properties, or copy/add/delete files/directories... -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] urllib bug in Python 3.2.1?
2011-08-09 08:02:45 Georg Brandl napisał(a): > Am 09.08.2011 01:35, schrieb Terry Reedy: > > On 8/8/2011 4:26 PM, Victor Stinner wrote: > >>>> With Python 3.1 and Python 3.2.1 it works OK, but with Python 3.2.1 the > >>>> read returns an empty string (I checked it myself). > >>> > >>> http://bugs.python.org/issue12576 > >> > >> The bug is now fixed. Can you release a Python 3.2.2, maybe only with > >> this fix? > > > > Any new release should also have > > http://bugs.python.org/issue12540 > > which fixes another bad regression. > > I can certainly release a version with these two fixes. Question is, should > we call it 3.2.2, or 3.2.1.1 (3.2.1p1)? I would suggest that a normal release with all changes committed on 3.2 branch be created. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 431 Time zone support improvements - Update
2012-12-29 19:54:42 Lennart Regebro napisał(a): > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver wrote: > > > - -Lots for enabling fallback by default except on platforms known not to > > have their own database > > Well, it's the same thing really. If the platform does have a database, the > fallback will not be used. I suggest that configure script support --enable-internal-timezone-database / --disable-internal-timezone-database options. --disable-internal-timezone-database should cause that installational targets in Makefile would not install files of timezone database. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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] test___all__ polluting sys.modules?
2012-12-30 15:48:30 R. David Murray napisał(a): > On Mon, 31 Dec 2012 00:38:47 +1000, Nick Coghlan wrote: > > However, specifically spinning out the "import the world" tests like > > test_pydoc and test___all__ to a separate process might be worth the > > effort. > > Adding something to regertest (or unittest?) so that certain nominated > test modules are run in a subprocess has been discussed previously, but > so far no one has stepped up to implement it :) Actually patches have been implemented about 2 years ago, but nobody committed them. http://bugs.python.org/issue1674555 > (I think this came up originally for test_site, but I don't remember for > sure.) Yes, test_site. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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
