Re: [Python-Dev] [Python-checkins] cpython: Issue #14435: Add Misc/NEWS and Misc/ACKS
Wishing to cause minimal disruption, I actually read http://docs.python.org/devguide/committing.html where this file is mentioned as part of the commit checklist. Never knew it existed before. K Frá: [email protected] [[email protected]] fyrir hönd Nick Coghlan [[email protected]] Sent: 1. apríl 2012 03:33 To: [email protected] Cc: [email protected] Efni: Re: [Python-checkins] cpython: Issue #14435: Add Misc/NEWS and Misc/ACKS On Sat, Mar 31, 2012 at 11:10 PM, kristjan.jonsson wrote: > diff --git a/Misc/ACKS b/Misc/ACKS > --- a/Misc/ACKS > +++ b/Misc/ACKS > @@ -507,6 +507,7 @@ > Richard Jones > Irmen de Jong > Lucas de Jonge > +Kristján Valur Jónsson > Jens B. Jorgensen > John Jorgensen > Sijin Joseph *blinks* This must have been one of those cases where everyone assumed your name was already there and never thought to check... Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-checkins mailing list [email protected] http://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On Sat, Mar 31, 2012 at 21:20, Terry Reedy wrote: > The Windows installer, by default, installs tcl/tk while Python on other > systems uses the system install. Why can't we do the same for the Olson > database? The problem is that it needs updating. We could include pytz, but it would be useless on Windows, unless you also separately installs the Olson database. But including it and updating it is not Python's job and should not be. //Lennart ___ Python-Dev mailing list [email protected] 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 418: Add monotonic clock
On Sat, Mar 31, 2012 at 11:50, Nadeem Vawda wrote: > Out of the big synonym list Guido posted, I rather like time.stopwatch() - it > makes it more explicit that the purpose of the function is to measure > intervals, > rather identifying absolute points in time. I guess it's the least bad. //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 14417: consequences of new dict runtime error
On 03/30/2012 03:25 PM, R. David Murray wrote: On Fri, 30 Mar 2012 15:13:36 -0400, Etienne Robillard wrote: So far I was only attempting to verify whether this is related to PEP-416 or not. If this is indeed related PEP 416, then I must obviously attest that I must still understand why a immutable dict would prevent this bug or not... OK, that seems to be the source of your confusion, then. This has nothing to do with PEP-416. We are talking about issue Issue 14417 (like it says in the subject), which in turn is a reaction to the fix for issue 14205. --David Don't be so naive, David. This issue is more likely related to immutable dicts whether you like it or not, otherwise there would be no need to patch python 3.3 and include a new dict proxy type without exposing it fully. And secondly this is not only a speculation but my humble understanding of the interdependencies which seems to be related to the inclusion of a new dict proxy (immutable) mapper affecting invariably code expecting a mutable dictionary lookup to succeed whenever the dict structure has changed by (ie) overriding __hash__. Now if you don't mind, I don't mind to remind you how cell phones can be unsafe on an extended period of times for your health and brain so I really don't recommend their uses for cloud-based platforms requiring more advanced thread locking mecanism than what is being included in traditional CPython using standard (mutable) dicts. Regards, Etienne ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .{git,bzr}ignore in cpython HG repo
Why does HG cpython repo contains .{bzr,git}ignore at all?
IMHO, all .*ignore files should be strictly repository dependent and
they should not be mixed together.
It is even worse, that (understandingly) .{bzr,git}ignore are apparently
poorly maintained, so in order to get an equivalent of .hgignore in
.gitignore, one has to apply the attached patch.
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
We understand our competition isn't with Caldera or SuSE--our
competition is with Microsoft.
-- Bob Young of Red Hat
http://www.linuxjournal.com/article/3553
--- _gitignore.orig 2012-03-30 16:49:38.388685137 +0200
+++ _gitignore.fixed2012-03-30 16:57:21.634708179 +0200
@@ -5,14 +5,18 @@
*.pyd
*.pyo
*.rej
+*.swp
*~
+.gdb_history
Doc/build/
Doc/tools/docutils/
+Doc/tools/jinja/
Doc/tools/jinja2/
Doc/tools/pygments/
Doc/tools/sphinx/
Lib/lib2to3/*.pickle
Lib/_sysconfigdata.py
+Lib/plat-mac/errors.rsrc.df.rsrc
Makefile
Makefile.pre
Misc/python.pc
@@ -31,20 +35,35 @@
PCbuild/*.o
PCbuild/*.pdb
PCbuild/Win32-temp-*
+PCbuild/amd64/
+.purify
Parser/pgen
Parser/pgen.stamp
__pycache__
autom4te.cache
build/
+buildno
+config.cache
+config.log
+config.status
+config.status.lineno
+core
+db_home
config.log
config.status
libpython*.a
libpython*.so*
+platform
pybuilddir.txt
pyconfig.h
python
+python.exe
python-gdb.py
+python.exe-gdb.py
+reflog.txt
+.svn/
tags
+TAGS
.coverage
coverage/
htmlcov/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] datetime module and pytz with dateutil
On 4/1/2012 9:16 AM, Lennart Regebro wrote: On Sat, Mar 31, 2012 at 21:20, Terry Reedy wrote: The Windows installer, by default, installs tcl/tk while Python on other systems uses the system install. Why can't we do the same for the Olson database? The problem is that it needs updating. We could include pytz, but it would be useless on Windows, unless you also separately installs the Olson database. But including it and updating it is not Python's job and should not be. My main point is that I (as a Windows's user) do not think that difficulties with Windows should stop inclusion of a useful module. On import, pytz should check for database accessibility and raise an exception if not, and possibly refer to manual section on how to make it accessible. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Fri, Mar 30, 2012 at 10:00, Matěj Cepl wrote:
> Why does HG cpython repo contains .{bzr,git}ignore at all?
> IMHO, all .*ignore files should be strictly repository dependent and they
> should not be mixed together.
For what reason? Are the git or bzr files causing issues on HG?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Fri, Mar 30, 2012 at 8:00 AM, Matěj Cepl wrote:
> Why does HG cpython repo contains .{bzr,git}ignore at all?
So that when people switch between repo software the set of ignored
files remains constant. While the "official" repo isn't going to
switch any time soon, various developers for various reasons prefer
different repo software and the tools for copying repos work well
enough that people actually do this, for various workflow purposes. As
long as patches eventually find their way back into the central Hg
repo I have no problem in it.
> IMHO, all .*ignore files should be strictly repository dependent and they
> should not be mixed together.
No, because then everybody who copies a repo to a different tool would
have to start over from scratch.
> It is even worse, that (understandingly) .{bzr,git}ignore are apparently
> poorly maintained, so in order to get an equivalent of .hgignore in
> .gitignore, one has to apply the attached patch.
Please file a bug to get this reviewed and checked in.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Somewhere at the edge of the Bell curve was the girl for me. -- Based on http://xkcd.com/314/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2012 06:31 PM, Matěj Cepl wrote: > On 1.4.2012 23:46, Brian Curtin wrote: >> For what reason? Are the git or bzr files causing issues on HG? > > No, but wrong .gitignore causes issues with git repo obtained via > hg-fast-import. If it is meant as an intentional sabotage of using git > (and bzr) for cpython, then that's the only explanation I can > understand, otherwise it doesn't make sense to me why these files are > in HG repository at all. Hanlon's Razor, paraphrased: "Never attribute to malice that which can be adqeuately explained by [bitrot]." Actually, the Goethe quote from [1] is even more apropos: "[M]isunderstandings and neglect create more confusion in this world than trickery and malice. At any rate, the last two are certainly much less frequent." [1] http://en.wikipedia.org/wiki/Hanlon's_razor Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk94868ACgkQ+gerLs4ltQ505gCghFGqdB6KUMExjxAxjkb1vGu2 /GMAn3k/wNqphKwancGHWageYGpefzTB =KJrm -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)
On 28Mar2012 23:40, Victor Stinner wrote: | > Does this primarily give a high resolution clock, or primarily a | > monotonic clock? That's not clear from either the name, or the PEP. | | I expect a better resolution from time.monotonic() than time.time(). I | don't have exact numbers right now, but I began to document each OS | clock in the PEP. I wish to raise an alternative to these set-in-stone policy-in-the-library choices, and an alternative to any proposal that does fallback in a function whose name suggests otherwise. Off in another thread on PEP 418 I suggested a cleaner approach to offering clocks to the user: let the user ask! My (just two!) posts on this are here: http://www.mail-archive.com/[email protected]/msg66174.html http://www.mail-archive.com/[email protected]/msg66179.html The second post is more important as it fleshes out my reasons for considering this appraoch better. I've just finished sketching out a skeleton here: https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py In short: - take Victor's hard work on system clocks and classifying thm by feature set - tabulate access to them in a list of clock objects - base access class goes (example user call): # get a clock object - often a singleton under the hood T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES) # what kind of clock did I get? print T.flags # get the current time now = T.now - offer monotonic() and/or steady() etc as convenience functions calling get_clock() in a fashion like the above example - don't try to guess the user's use case ahead of time This removes policy from the library functions and makes it both simple and obvious in the user's calling code, and also makes it possible for the user to inspect the clock and find out what quality/flavour of clock they got. Please have a glance through the code, especially the top and botth bits; it is only 89 lines long and includes (presently) just a simple object for time.time() and (importantly for the bikeshedding) an example synthetic clock to give a monotonic caching clock from another non-monotonic clock (default, again, time.time() in this prototype). Suitably fleshed out with access to the various system clocks, this can offer all the current bikeshedding in a simple interface and without constraining user choices to "what we thought of, or what we thought likely". Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Availability: Samples Q1/97 Volume H2/97 So, it's vapor right now, but if you want to sell vapor in 1997 you better had damn fast vapor then... - Burkhard Neidecker-Lutz on the DEC Alpha 21264, October 1996 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote: > On 1.4.2012 23:46, Brian Curtin wrote: >> >> For what reason? Are the git or bzr files causing issues on HG? > > > No, but wrong .gitignore causes issues with git repo obtained via > hg-fast-import. If it is meant as an intentional sabotage of using git (and > bzr) for cpython, then that's the only explanation I can understand, > otherwise it doesn't make sense to me why these files are in HG repository > at all. Then you won't understand. Sometimes things get out of date when they aren't used or maintained. You're welcome to fix the problem if you're a Git user, as suggested earlier. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
On Sat, Mar 31, 2012 at 8:46 AM, Guido van Rossum wrote: > Given the amount of disagreement I sense, I think we'll need to wait > for more people to chime in. I currently can't imagine why I *personally* would want anything better than what we currently call time.time. For that reason, I like Cameron's proposal best. If and when I have a use case, I'll be able to query the system for the clock that has the best combination of desirable properties. Admittedly, by then the answer probably will be "time.time." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On Mon, Apr 2, 2012 at 8:31 AM, Matěj Cepl wrote: > On 1.4.2012 23:46, Brian Curtin wrote: >> >> For what reason? Are the git or bzr files causing issues on HG? > > > No, but wrong .gitignore causes issues with git repo obtained via > hg-fast-import. If it is meant as an intentional sabotage of using git (and > bzr) for cpython, then that's the only explanation I can understand, > otherwise it doesn't make sense to me why these files are in HG repository > at all. As Guido explained, the bzr and git ignore files are there to allow Git and Bzr users to collaborate on them, updating a standard copy when the .hgignore entries change (which doesn't happen very often). If they get outdated (or otherwise contain erroneous entries), then the appropriate response is to either update them directly (core developers that use a different DVCS for their local workflow), or raise a tracker issue pointing out they they have become stale (everyone else that uses a different DVCS for their local workflow). Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
On 3/30/2012 11:00 AM, Matěj Cepl wrote:
> It is even worse, that (understandingly) .{bzr,git}ignore are apparently
> poorly maintained, so in order to get an equivalent of .hgignore in
> .gitignore, one has to apply the attached patch.
Create an issue on the bug tracker. In the meantime, you can either
commit the change to your clone, or you can put your ignores into
.git/info/exclude. No reason to be so sore about it, since Git lets you
have your own ignore file without requiring it be a tracked file.
--
Scott Dial
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.0 alpha 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm happy to announce the
second alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The new "packaging" module, building upon the "distribute" and
"distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html (*)
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
- --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F
zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu
=qo4v
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.0 alpha 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm happy to announce the
second alpha release of Python 3.3.0.
This is a preview release, and its use is not recommended in
production settings.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, Syntax for Delegating to a Subgenerator ("yield from")
* PEP 393, Flexible String Representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* PEP 409, Suppressing Exception Context
* PEP 3151, Reworking the OS and IO exception hierarchy
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The new "packaging" module, building upon the "distribute" and
"distutils2" projects and deprecating "distutils"
* The new "lzma" module with LZMA/XZ support
* PEP 3155, Qualified name for classes and functions
* PEP 414, explicit Unicode literals to help with porting
* The new "faulthandler" module that helps diagnosing crashes
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html (*)
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
Please consider trying Python 3.3.0 with your code and reporting any bugs
you may notice to:
http://bugs.python.org/
Enjoy!
(*) Please note that this document is usually finalized late in the release
cycle and therefore may have stubs and missing entries at this point.
- - --
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
- -BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAk95PJgACgkQN9GcIYhpnLCN1QCfeYWp+QbPGYhaLSxc4YKnlE/F
zU8An2q5qzvjL0qaxqaYleFGoGKPzzJu
=qo4v
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAk95P10ACgkQN9GcIYhpnLBo8QCePW2BuTqXSmtVl6/Yae1HWrGB
UFgAn0ytSqd70vq58gj9N8xUtKC+BJ2D
=3DA/
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo
Am 02.04.2012 00:31, schrieb Matěj Cepl: > On 1.4.2012 23:46, Brian Curtin wrote: >> For what reason? Are the git or bzr files causing issues on HG? > > No, but wrong .gitignore causes issues with git repo obtained via > hg-fast-import. If it is meant as an intentional sabotage of using git > (and bzr) for cpython, then that's the only explanation I can > understand, otherwise it doesn't make sense to me why these files are in > HG repository at all. > Sabotage, most certainly. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
