Re: [Python-Dev] Drop the new time.wallclock() function?
Do you really want to add an obscure Boolean flag to the function just so that python can warn you that perhaps your platform is so old and so weird that Python can't guarantee that the performance measurements are to a certain _undefined_ quality? Please note, that the function makes no claims to the resolution or precision of the timer involved. Only that it moves only forward. It is therefore completely and utterly redundant to add a "strict" value, because we would only be behave "strictly" according to an _undefined specification_. K -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Lennart Regebro Sent: 15. mars 2012 04:44 To: Matt Joiner Cc: Python Dev Subject: Re: [Python-Dev] Drop the new time.wallclock() function? On Thu, Mar 15, 2012 at 02:58, Matt Joiner wrote: > Victor, I think that steady can always be monotonic, there are time > sources enough to ensure this on the platforms I am aware of. Strict > in this sense refers to not being adjusted forward, i.e. > CLOCK_MONOTONIC vs CLOCK_MONOTONIC_RAW. > > Non monotonicity of this call should be considered a bug. Strict would > be used for profiling where forward leaps would disqualify the timing. This makes sense to me. //Lennart ___ 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/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (built-in virtualenv) status
Hi Carl. I'm very interested in this work. At CCP we work heavily with virtual environments. Except that we don't use virtualenv because it is just a pain in the neck. We like to be able to run virtual python environments of various types as they arrive checked out of source control repositories, without actually "installing" anything. For some background, please see: http://blog.ccpgames.com/kristjan/2010/10/09/using-an-isolated-python-exe/. It's a rather quick read, actually. The main issue for us is: How to prevent your local python.exe from reading environment variables and running some global site.py? There are a number of points raised in the above blog, please take a look at the "Musings" at the end. Best regards, Kristján -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Carl Meyer Sent: 15. mars 2012 22:12 To: python-dev Subject: Re: [Python-Dev] PEP 405 (built-in virtualenv) status On 03/15/2012 03:02 PM, Lindberg, Van wrote: > FYI, the location of the tcl/tk libraries does not appear to be set in > the virtualenv, even if tkinter is installed and working in the main > Python installation. As a result, tk-based apps will not run from a > virtualenv. Thanks for the report! I've added this to the list of open issues in the PEP and I'll look into it. Carl ___ 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] svn.python.org and buildbots down
Hello, you might be aware of it already. In case not, it appears that svn.python.org and the buildbots are down. Stefan Krah ___ 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] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
> I have to agree with Georg. Looking at the code, it appears OSError can > be raised with both strict=True and strict=False (since floattime() can > raise OSError). This is an old bug in floattime(): I opened the issue #14368 to remove the unused exception. In practice, it never happens (or it is *very* unlikely today). IMO it's a bug in floattime(). > I also think "By default, if strict is False" confuses things. I agree, I replaced it by "By default,". Victor ___ 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] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
>>> This is not clear to me. Why wouldn't it raise OSError on error even with >>> strict=False? Please clarify which exception is raised in which case. >> >> It seems clear to me. It doesn't raise exceptions when strict=False because >> it falls back to a non-monotonic clock. If strict is True and a non-monotonic >> clock is not available it raises OSError or NotImplementedError. > > So errors are ignored when strict is false? Said differently: time.steady(strict=True) is always monotonic (*), whereas time.steady() may or may not be monotonic, depending on what is avaiable. time.steady() is a best-effort steady clock. (*) time.steady(strict=True) relies on the OS monotonic clock. If the OS provides a "not really monotonic" clock, Python cannot do better. For example, clock_gettime(CLOCK_MONOTONIC) speed can be adjusted by NTP on Linux. Python tries to use clock_gettime(CLOCK_MONOTONIC_RAW) which doesn't have this issue. Victor ___ 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] svn.python.org and buildbots down
On Mon, 19 Mar 2012 13:26:37 +0100 Stefan Krah wrote: > Hello, > > you might be aware of it already. In case not, it appears that svn.python.org > and the buildbots are down. The buildbots should be back now. As for svn.python.org, is anyone using it? (I don't know how to restart it) Regards 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] svn.python.org and buildbots down
Antoine Pitrou wrote: > The buildbots should be back now. As for svn.python.org, is anyone > using it? (I don't know how to restart it) Thanks! I'm using svn.python.org for the automated sphinx checkout in Doc/ (make html) and sometimes to dig through pre-hg history. But don't bother to find out how to restart it just for me. I presume Martin knows the setup and will do it later. Stefan Krah ___ 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] cpython: Issue #14347: Update Misc/README list of files.
The two files that were added back in should probably just disappear (README.aix and README.coverty). Anyone disagree? On Sat, Mar 17, 2012 at 13:52, ned.deily wrote: > http://hg.python.org/cpython/rev/65a0a6fab127 > changeset: 75797:65a0a6fab127 > user:Ned Deily > date:Sat Mar 17 10:52:08 2012 -0700 > summary: > Issue #14347: Update Misc/README list of files. > (Initial patch by Dionysios Kalofonos) > > files: > Misc/README | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > diff --git a/Misc/README b/Misc/README > --- a/Misc/README > +++ b/Misc/README > @@ -8,7 +8,6 @@ > > > ACKSAcknowledgements > -build.shScript to build and test latest Python from the > repository > gdbinit Handy stuff to put in your .gdbinit file, if you > use gdb > HISTORY News from previous releases -- oldest last > indent.pro GNU indent profile approximating my C style > @@ -19,6 +18,8 @@ > python.pc.inPackage configuration info template for > pkg-config > python-wing*.wprWing IDE project file > README The file you're reading now > +README.AIX Information about using Python on AIX > +README.coverity Information about running Coverity's Prevent on > Python > README.valgrind Information for Valgrind users, see > valgrind-python.supp > RPM (Old) tools to build RPMs > svnmap.txt Map of old SVN revs and branches to hg changeset > ids > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins > > ___ 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] cpython: Issue #14347: Update Misc/README list of files.
On Mon, 19 Mar 2012 10:56:02 -0400 Brett Cannon wrote: > The two files that were added back in should probably just disappear > (README.aix and README.coverty). Anyone disagree? README.AIX was recently updated in http://bugs.python.org/issue10709. Regards 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
[Python-Dev] regarding HTML mail
apology: I searched for a few minutes and could not find a code of conduct regarding HTML mail. Can we have some guideline to allow only plain text emails, so as to avoid cases like http://mail.python.org/pipermail/docs/2012-March/007999.html, where you are forced to scroll horizontally in order to read the text. ___ 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] svn.python.org and buildbots down
In article <20120319142539.7e83c...@pitrou.net>, Antoine Pitrou wrote: > [...] As for svn.python.org, is anyone > using it? The repo for the website (www.python.org) is maintained there. -- Ned Deily, n...@acm.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] PEP 405 (built-in virtualenv) status
On 3/19/2012 2:26 AM, Kristján Valur Jónsson wrote: Hi Carl. I'm very interested in this work. At CCP we work heavily with virtual environments. Except that we don't use virtualenv because it is just a pain in the neck. We like to be able to run virtual python environments of various types as they arrive checked out of source control repositories, without actually "installing" anything. For some background, please see:http://blog.ccpgames.com/kristjan/2010/10/09/using-an-isolated-python-exe/. It's a rather quick read, actually. The main issue for us is: How to prevent your local python.exe from reading environment variables and running some global site.py? There are a number of points raised in the above blog, please take a look at the "Musings" at the end. Best regards, Kristján I found that a very interesting reverse-engineering of what needs to be done to isolate multiple pythons on a machine. I concur that this is a feature that would be good to: 1) at least document the behavior well 2) preferably make an extensible feature, along the lines that Kristján suggests There are likely some bootstrapping issues, but I find the idea that the difference between an embedded Python and an installed Python and a built-but-not-installed Python being conceptually isolated to the python.exe and/or site.py rather than python.dll to be a clever concept; of course, where the code lives is less relevant than the conditions under which it is invoked; I doubt the size of the code is the issue regarding where it lives. ___ 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] regarding HTML mail
On Mar 19, 2012, at 05:25 PM, Tshepang Lekhonkhobe wrote: >apology: I searched for a few minutes and could not find a code of >conduct regarding HTML mail. I'm not sure it's written down anywhere, but in general we strongly discourage HTML email for the lists @python.org >Can we have some guideline to allow only plain text emails, so as to >avoid cases like >http://mail.python.org/pipermail/docs/2012-March/007999.html, where >you are forced to scroll horizontally in order to read the text. docs is a different mailing list than python-dev, but still neither list is doing any content filtering. We could always enable that if we wanted to get strict about it. In this case, this isn't html email, it's likely this bug: https://bugs.launchpad.net/mailman/+bug/558294 Cheers, -Barry ___ 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] regarding HTML mail
I'd like to discuss top-posting. On Monday, March 19, 2012 at 2:20 PM, Barry Warsaw wrote: > On Mar 19, 2012, at 05:25 PM, Tshepang Lekhonkhobe wrote: > > > apology: I searched for a few minutes and could not find a code of > > conduct regarding HTML mail. > > > > I'm not sure it's written down anywhere, but in general we strongly discourage > HTML email for the lists @python.org (http://python.org) > > > Can we have some guideline to allow only plain text emails, so as to > > avoid cases like > > http://mail.python.org/pipermail/docs/2012-March/007999.html, where > > you are forced to scroll horizontally in order to read the text. > > > > docs is a different mailing list than python-dev, but still neither list is > doing any content filtering. We could always enable that if we wanted to get > strict about it. > > In this case, this isn't html email, it's likely this bug: > > https://bugs.launchpad.net/mailman/+bug/558294 > > Cheers, > -Barry > ___ > Python-Dev mailing list > Python-Dev@python.org (mailto:Python-Dev@python.org) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] svn.python.org and buildbots down
On Mar 19, 2012 1:20 PM, "Ned Deily" wrote: > > In article <20120319142539.7e83c...@pitrou.net>, > Antoine Pitrou wrote: > > [...] As for svn.python.org, is anyone > > using it? > > The repo for the website (www.python.org) is maintained there. It's also still setuptools' official home, though I've been doing some work recently on migrating it to hg. ___ 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] regarding HTML mail
On 3/19/2012 11:52 AM, Jesse Noller wrote: I'd like to discuss top-posting. Somewhere else, please. Oh, that was your point :) ___ 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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
In http://mail.python.org/pipermail/python-dev/2012-March/117570.html Steven D'Aprano posted: > "Need" is awfully strong. I don't believe it is the responsibility > of the standard library to be judge and reviewer of third party > packages that it doesn't control. It is, however, user-friendly to indicate when the stdlib selections are particularly likely to be for reasons other than "A bunch of experts believe this is the best way to do this." Cpython's documentation is (de facto) the documentation for python in general, and pointing people towards other resources (particularly pypi itself) is quite reasonable. Many modules are in the stdlib in part because they are an *acceptable* way of doing something, and the "best" ways are either changing too quickly or are so complicated that it doesn't make sense to burden the *standard* libary for specialist needs. In those cases, I do think the documentation should say so. Specific examples: http://docs.python.org/library/numeric.html quite reasonably has subsections only for what ships with Python. But I think the introductory paragraph could stand to have an extra sentence explaining why and when people should look beyond the stanard library, such as: Applications centered around mathematics may benefit from specialist 3rd party libraries, such as numpy < http://pypi.python.org/pypi/numpy/ >, gmpy < http://pypi.python.org/pypi/gmpy >, and scipy< http://pypi.python.org/pypi/scipy >. I would add a similar sentence to the web section, or the internet protocols section if web is still not broken out separately. http://docs.python.org/dev/library/internet.html Note that some web conventions are still evolving too quickly for covenient encapsulation in a stable library. Many applications will therefore prefer functional replacements from third parties, such as requests or httplib2, or frameworks such as Django and Zope. www-related products can be found by browsing PyPI for top internet subtopic www/http. < http://pypi.python.org/pypi?:action=browse&c=319&c=326 > [I think that searching by classifier -- which first requires browse, and can't be reached from the list of classifiers -- could be improved.] > Should we recommend wxPython over Pyjamas or PyGUI or PyGtk? Actually, I think the existing http://docs.python.org/library/othergui.html does a pretty good job; I would not object to adding mentions of other tools as well, but wiki reference is probably sufficient. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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 405 (built-in virtualenv) status
Hello Kristján, On 03/19/2012 03:26 AM, Kristján Valur Jónsson wrote: > Hi Carl. I'm very interested in this work. At CCP we work heavily > with virtual environments. Except that we don't use virtualenv > because it is just a pain in the neck. We like to be able to run > virtual python environments of various types as they arrive checked > out of source control repositories, without actually "installing" > anything. For some background, please see: > http://blog.ccpgames.com/kristjan/2010/10/09/using-an-isolated-python-exe/. > It's a rather quick read, actually. > > The main issue for us is: How to prevent your local python.exe from > reading environment variables and running some global site.py? > > There are a number of points raised in the above blog, please take a > look at the "Musings" at the end. Thanks, I read the blog post. I think there are some useful points there; I too find the startup sys.path behavior of Python a bit more complex and magical than I'd prefer (I'm sure it's grown organically over the years to address a variety of different needs and concerns, not all of which I understand or am even aware of). I think there's one important (albeit odd and magical) bit of Python's current behavior that you are missing in your blog post. All of the initial sys.path directories are constructed relative to sys.prefix and sys.exec_prefix, and those values in turn are determined (if PYTHONHOME is not set), by walking up the filesystem tree from the location of the Python binary, looking for the existence of a file at the relative path "lib/pythonX.X/os.py" (or "Lib/os.py" on Windows). Python takes the existence of this file to mean that it's found the standard library, and sets sys.prefix accordingly. Thus, you can achieve reliable full isolation from any installed Python, with no need for environment variables, simply by placing a file (it can even be empty) at that relative location from the location of your Python binary. You will still get some default paths added on sys.path, but they will all be relative to your Python binary and thus presumably under your control; nothing from any other location will be on sys.path. I doubt you will find this solution satisfyingly elegant, but you might nonetheless find it practically useful. The essence of PEP 405 is simply to provide a less magical way to achieve this same result, by locating a "pyvenv.cfg" file next to (or one directory up from) the Python binary. The bulk of the work in PEP 405 is aimed towards a rather different goal from yours - to be able to share an installed Python's copy of the standard library among a number of virtual environments. This is the purpose of the "home" key in pyvenv.cfg and the added sys.base_prefix (which point to the Python installation whose standard library will be used). I think this serves a valuable and common use case, but I wonder if your use case couldn't also be served with a minor tweak to PEP 405. Currently it ignores a pyvenv.cfg file with no "home" key; instead, it could set sys.prefix and sys.base_prefix both to the location of that pyvenv.cfg. For most purposes, this would result in a broken Python (no standard library), but it might help you? Beyond that possible tweak, while I certainly wouldn't oppose any effort to clean up / document / make-optional Python's startup sys.path-setting behavior, I think it's mostly orthogonal to PEP 405, and I don't think it would be helpful to expand the scope of PEP 405 to include that effort. Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP czar for PEP 3144?
Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. Having only one function return a list instead of an iterator seems questionable. Depending on the code it could either keep track of what it has returned so far in a set and avoid duplication that way; or, just return an `iter(listobject)` instead of `listobject`. ~Ethan~ ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: > Nick Coghlan wrote: >> >> Collapsing the address list has to build the result list anyway to >> actually handle the deduplication part of its job, so returning a >> concrete list makes sense in that case. > > > Having only one function return a list instead of an iterator seems > questionable. > > Depending on the code it could either keep track of what it has returned so > far in a set and avoid duplication that way; or, just return an > `iter(listobject)` instead of `listobject`. I know I'm lacking context, but is the list ever expected to be huge? If not, what's wrong with always returning a list? -- --Guido van Rossum (python.org/~guido) ___ 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 czar for PEP 3144?
Guido van Rossum wrote: On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. Having only one function return a list instead of an iterator seems questionable. Depending on the code it could either keep track of what it has returned so far in a set and avoid duplication that way; or, just return an `iter(listobject)` instead of `listobject`. I know I'm lacking context, but is the list ever expected to be huge? If not, what's wrong with always returning a list? Nothing wrong in and of itself. It just seems to me that if we have several functions that deal with ip addresses/networks/etc, and all but one return iterators, that one is going to be a pain... 'Which one returns a list again? Oh yeah, that one.' Granted it's mostly a stylistic preference for consistency. ~Ethan~ ___ 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 405 (built-in virtualenv) status
Carl Meyer wrote: The bulk of the work in PEP 405 is aimed towards a rather different goal from yours - to be able to share an installed Python's copy of the standard library among a number of virtual environments. This is the purpose of the "home" key in pyvenv.cfg and the added sys.base_prefix (which point to the Python installation whose standard library will be used). I think this serves a valuable and common use case, but I wonder if your use case couldn't also be served with a minor tweak to PEP 405. Currently it ignores a pyvenv.cfg file with no "home" key; instead, it could set sys.prefix and sys.base_prefix both to the location of that pyvenv.cfg. For most purposes, this would result in a broken Python (no standard library), but it might help you? Instead of no home key, how about an empty home key? Explicit being better, and all that. ~Ethan~ ___ 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] cpython (2.7): Fixes Issue 14234: fix for the previous commit, keep compilation when
Does this mean that if Python is updated before expat, python will
compile out the expat randomization, and therefore not use if even
after expat is updated?
-jJ
On Thu, Mar 15, 2012 at 2:01 PM, benjamin.peterson
wrote:
> http://hg.python.org/cpython/rev/ada6bfbeceb8
> changeset: 75699:ada6bfbeceb8
> branch: 2.7
> user: Gregory P. Smith
> date: Wed Mar 14 18:12:23 2012 -0700
> summary:
> Fixes Issue 14234: fix for the previous commit, keep compilation when
> using --with-system-expat working when the system expat does not have
> salted hash support.
>
> files:
> Modules/expat/expat.h | 2 ++
> Modules/pyexpat.c | 5 +
> 2 files changed, 7 insertions(+), 0 deletions(-)
>
>
> diff --git a/Modules/expat/expat.h b/Modules/expat/expat.h
> --- a/Modules/expat/expat.h
> +++ b/Modules/expat/expat.h
> @@ -892,6 +892,8 @@
> XML_SetHashSalt(XML_Parser parser,
> unsigned long hash_salt);
>
> +#define XML_HAS_SET_HASH_SALT /* Python Only: Defined for pyexpat.c. */
> +
> /* If XML_Parse or XML_ParseBuffer have returned XML_STATUS_ERROR, then
> XML_GetErrorCode returns information about the error.
> */
> diff --git a/Modules/pyexpat.c b/Modules/pyexpat.c
> --- a/Modules/pyexpat.c
> +++ b/Modules/pyexpat.c
> @@ -1302,8 +1302,13 @@
> else {
> self->itself = XML_ParserCreate(encoding);
> }
> +#if ((XML_MAJOR_VERSION >= 2) && (XML_MINOR_VERSION >= 1)) ||
> defined(XML_HAS_SET_HASH_SALT)
> + /* This feature was added upstream in libexpat 2.1.0. Our expat copy
> + * has a backport of this feature where we also define
> XML_HAS_SET_HASH_SALT
> + * to indicate that we can still use it. */
> XML_SetHashSalt(self->itself,
> (unsigned long)_Py_HashSecret.prefix);
> +#endif
> self->intern = intern;
> Py_XINCREF(self->intern);
> #ifdef Py_TPFLAGS_HAVE_GC
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
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] cpython (2.7): Fixes Issue 14234: fix for the previous commit, keep compilation when
2012/3/19 Jim Jewett : > Does this mean that if Python is updated before expat, python will > compile out the expat randomization, and therefore not use if even > after expat is updated? If you're using --with-system-expat -- Regards, Benjamin ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote: > Guido van Rossum wrote: >> >> On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: >>> >>> Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. >>> >>> >>> Having only one function return a list instead of an iterator seems >>> questionable. >>> >>> Depending on the code it could either keep track of what it has returned >>> so >>> far in a set and avoid duplication that way; or, just return an >>> `iter(listobject)` instead of `listobject`. >> >> >> I know I'm lacking context, but is the list ever expected to be huge? >> If not, what's wrong with always returning a list? > > > Nothing wrong in and of itself. It just seems to me that if we have several > functions that deal with ip addresses/networks/etc, and all but one return > iterators, that one is going to be a pain... 'Which one returns a list > again? Oh yeah, that one.' It depends on whether they really are easy to confuse. If they are, indeed that feels like poor API design. But sometimes the only time two things seem confusingly similar is when you have not actually tried to use them. A naming convention often helps too. > Granted it's mostly a stylistic preference for consistency. And remember that consistency is good in moderation, but if it becomes a goal in itself you may have a problem. -- --Guido van Rossum (python.org/~guido) ___ 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] svn.python.org and buildbots down
> But don't bother to find out how to restart it just for me. I presume > Martin knows the setup and will do it later. It seems to be working fine now, and I didn't do anything. Thomas rebooted the system for hardware inspection at 15:02 (and brought it back up at 15:18), so most likely, it started as part of the regular boot process (as it should have done on the previous reboot as well). Regards, Martin P.S. FWIW, the hardware inspection didn't reveal any hardware problems, so it remains unclear what is causing the outages. ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote: > On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: >> Nick Coghlan wrote: >>> >>> Collapsing the address list has to build the result list anyway to >>> actually handle the deduplication part of its job, so returning a >>> concrete list makes sense in that case. >> >> >> Having only one function return a list instead of an iterator seems >> questionable. >> >> Depending on the code it could either keep track of what it has returned so >> far in a set and avoid duplication that way; or, just return an >> `iter(listobject)` instead of `listobject`. > > I know I'm lacking context, but is the list ever expected to be huge? > If not, what's wrong with always returning a list? It's possible to return massive lists, (eg, returning the 4+ billion /128 subnets in /96 or something even larger, but I don't think that's very common). I've generally tried to avoid confusion by having 'iter' in the iterating methods, but if more of the methods return iterators, maybe I need to rethink that? > -- > --Guido van Rossum (python.org/~guido) > ___ > 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/pmoody%40google.com -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038 ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 2:58 PM, Peter Moody wrote: > On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote: >> On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: >>> Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. >>> >>> >>> Having only one function return a list instead of an iterator seems >>> questionable. >>> >>> Depending on the code it could either keep track of what it has returned so >>> far in a set and avoid duplication that way; or, just return an >>> `iter(listobject)` instead of `listobject`. >> >> I know I'm lacking context, but is the list ever expected to be huge? >> If not, what's wrong with always returning a list? > > It's possible to return massive lists, (eg, returning the 4+ billion > /128 subnets in /96 or something even larger, but I don't think that's > very common). I've generally tried to avoid confusion by having 'iter' > in the iterating methods, but if more of the methods return iterators, > maybe I need to rethink that? I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. -- --Guido van Rossum (python.org/~guido) ___ 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 czar for PEP 3144?
Guido van Rossum wrote: On Mon, Mar 19, 2012 at 1:13 PM, Ethan Furman wrote: Nothing wrong in and of itself. It just seems to me that if we have several functions that deal with ip addresses/networks/etc, and all but one return iterators, that one is going to be a pain... 'Which one returns a list again? Oh yeah, that one.' It depends on whether they really are easy to confuse. If they are, indeed that feels like poor API design. But sometimes the only time two things seem confusingly similar is when you have not actually tried to use them. Heh -- true, I have not tried to use them (yet) -- just offering another viewpoint. ;) Granted it's mostly a stylistic preference for consistency. And remember that consistency is good in moderation, but if it becomes a goal in itself you may have a problem. While I agree that consistency as a goal in and of itself is not good, I consider it more important than 'moderation' implies; in my own code I try to only be inconsistent when there is a good reason to be. To me, "it's already a list" isn't a good reason -- yes, that's easier for the library author, but is it easier for the library user? What is the library user gaining by having a list returned instead of an iterator? Of course, the flip-side also holds: what is the library user losing by getting an iterator when a list was available? When we way the pros and cons, and it comes down to a smidgeon of performance in trade for consistency [1], I would vote for consistency. ~Ethan~ [1] I'm assuming that 'iter(some_list)' is a quick operation. ___ 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 czar for PEP 3144?
On 3/19/2012 6:04 PM, Guido van Rossum wrote: On Mon, Mar 19, 2012 at 2:58 PM, Peter Moody wrote: On Mon, Mar 19, 2012 at 12:55 PM, Guido van Rossum wrote: On Mon, Mar 19, 2012 at 12:37 PM, Ethan Furman wrote: Nick Coghlan wrote: Collapsing the address list has to build the result list anyway to actually handle the deduplication part of its job, so returning a concrete list makes sense in that case. Having only one function return a list instead of an iterator seems questionable. Depending on the code it could either keep track of what it has returned so far in a set and avoid duplication that way; or, just return an `iter(listobject)` instead of `listobject`. I know I'm lacking context, but is the list ever expected to be huge? If not, what's wrong with always returning a list? It's possible to return massive lists, (eg, returning the 4+ billion /128 subnets in /96 or something even larger, but I don't think that's very common). I've generally tried to avoid confusion by having 'iter' in the iterating methods, but if more of the methods return iterators, maybe I need to rethink that? I personally like having 'iter' in the name (e.g. iterkeys() -- note that we dropped this in Py3k because it's no longer an iterator, it's a dict view now. But I don't want to promote that style for ipaddr.py. I am not sure which way you are pointing, but the general default in 3.x is to return iterators: range, zip, enumerate, map, filter, reversed, open (file objects), as well at the dict methods. I am quite happy to be rid of the 'iter' prefix on the latter. This is aside from itertools. The main exceptions I can think of are str.split and sorted. For sorted, a list *must* be constructed anyway, so might as well return it. This apparently matches the case under consideration. If name differentiation is wanted, call it xxxlist. -- Terry Jan Reedy ___ 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] svn.python.org and buildbots down
On 3/19/2012 9:25 AM, Antoine Pitrou wrote: The buildbots should be back now. As for svn.python.org, is anyone using it? Last I knew, some files there are required to fully build Python on Windows. I would be happy if that has or were to change. -- Terry Jan Reedy ___ 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 czar for PEP 3144?
On Mon, Mar 19, 2012 at 3:44 PM, Terry Reedy wrote: > I am not sure which way you are pointing, but the general default in 3.x is > to return iterators: range, zip, enumerate, map, filter, reversed, open > (file objects), as well at the dict methods. Actually as I tried to say, the dict methods (keys() etc.) DON'T return iterators. They return "views" which are iterable. Anyway, I also tried to imply that it matters if the number of list items would ever be huge. It seems that is indeed possible (even if not likely) so I think iterators are useful. > I am quite happy to be rid of > the 'iter' prefix on the latter. This is aside from itertools. The main > exceptions I can think of are str.split and sorted. For sorted, a list > *must* be constructed anyway, so might as well return it. This apparently > matches the case under consideration. If name differentiation is wanted, > call it xxxlist. Agreed, ideally you don't need to know or it'll be obvious from the name without an explicit 'list' or 'iter'. -- --Guido van Rossum (python.org/~guido) ___ 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 czar for PEP 3144?
On Tue, Mar 20, 2012 at 8:34 AM, Guido van Rossum wrote: > Anyway, I also tried to imply that it matters if the number of list > items would ever be huge. It seems that is indeed possible (even if > not likely) so I think iterators are useful. But according to Nick's post, there's some sort of uniquification that is done, and the algorithm currently used computes the whole list anyway. I suppose that one could do the uniquification lazily, or find some other way to avoid that computation. Is it worth it to optimize an unlikely case? ___ 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 czar for PEP 3144?
On Tue, Mar 20, 2012 at 10:43 AM, Stephen J. Turnbull wrote: > But according to Nick's post, there's some sort of uniquification that > is done, and the algorithm currently used computes the whole list anyway. > > I suppose that one could do the uniquification lazily, or find some other > way to avoid that computation. Is it worth it to optimize an unlikely case? Yeah, the only where I thought retaining the list output made particular sense was "collapse_address_list". I have no problem with that operation expecting a real sequence as input and producing an actual list as output, since the entire (deduplicated) sequence will eventually end up in memory for checking purposes anyway, even if the result was an iterator rather than a list and it already has "list" in its name. The other instances I noticed should all just be a matter of replacing "output.append(value)" calls with "yield value" instead, so it seems sensible to standardise on a Py3k style iterators-instead-of-lists API for the standard library version of the module. 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] PEP czar for PEP 3144?
On Mon, Mar 19, 2012 at 02:50:22PM -0700, Ethan Furman wrote: > Guido van Rossum wrote: [...] > >And remember that consistency is good in moderation, but if it becomes > >a goal in itself you may have a problem. > > While I agree that consistency as a goal in and of itself is not good, I > consider it more important than 'moderation' implies; in my own code I > try to only be inconsistent when there is a good reason to be. I think we're probably in violent agreement, but I would put it this way: Consistency for its own sake *is* good, since consistency makes it easier for people to reason about the behaviour of functions on the basis that they are similar to other functions. But it is not the *only* good, and it is legitimate to trade-off one good for another good as needed. > To me, "it's already a list" isn't a good reason -- yes, that's easier > for the library author, but is it easier for the library user? What is > the library user gaining by having a list returned instead of an iterator? I guess this discussion really hinges on which of these two positions you take: 1. The function naturally returns a list, should we compromise that simplicity by returning an iterator to be consistent with the other related/similar functions in the library? 2. These related/similar functions naturally return iterators, should we compromise that consistency by allowing one of them to return a list as it simplifies the implementation? > Of course, the flip-side also holds: what is the library user losing by > getting an iterator when a list was available? > > When we way the pros and cons, and it comes down to a smidgeon of > performance in trade for consistency [1], I would vote for consistency. I lean that way as well. > ~Ethan~ > > [1] I'm assuming that 'iter(some_list)' is a quick operation. For very small lists, it's about half as expensive as creating the list in the first place: steve@runes:~$ python3.2 -m timeit -s "x = (1,2,3)" "list(x)" 100 loops, best of 3: 0.396 usec per loop steve@runes:~$ python3.2 -m timeit -s "x = (1,2,3)" "iter(list(x))" 100 loops, best of 3: 0.614 usec per loop For large lists, it's approximately free: steve@runes:~$ python3.2 -m timeit -s "x = (1,2,3)*1" "list(x)" 1 loops, best of 3: 111 usec per loop steve@runes:~$ python3.2 -m timeit -s "x = (1,2,3)*1" "iter(list(x))" 1 loops, best of 3: 111 usec per loop On the other hand, turning the list iterator into a list again is probably not quite so cheap. -- Steven ___ 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] Issue #10278 -- why not just an attribute?
In http://mail.python.org/pipermail/python-dev/2012-March/117762.html Georg Brandl posted: >> + If available, a monotonic clock is used. By default, if *strict* is >> False, >> + the function falls back to another clock if the monotonic clock failed >> or is >> + not available. If *strict* is True, raise an :exc:`OSError` on error or >> + :exc:`NotImplementedError` if no monotonic clock is available. > This is not clear to me. Why wouldn't it raise OSError on error even with > strict=False? Please clarify which exception is raised in which case. Passing strict as an argument seems like overkill since it will always be meaningless on some (most?) platforms. Why not just use a function attribute? Those few users who do care can check the value of time.steady.monotonic before calling time.steady(); exceptions raised will always be whatever the clock actually raises. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ 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] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote: > Said differently: time.steady(strict=True) is always monotonic (*), > whereas time.steady() may or may not be monotonic, depending on what > is avaiable. > > time.steady() is a best-effort steady clock. > > (*) time.steady(strict=True) relies on the OS monotonic clock. If the > OS provides a "not really monotonic" clock, Python cannot do better. I don't think that is true. Surely Python can guarantee that the clock will never go backwards by caching the last value. A sketch of an implementation: def monotonic(_last=[None]): t = system_clock() # best effort, but sometimes goes backwards if _last[0] is not None: t = max(t, _last[0]) _last[0] = t return t Overhead if done in Python may be excessive, in which case do it in C. Unless I've missed something, that guarantees monotonicity -- it may not advance from one call to the next, but it will never go backwards. There's probably even a cleverer implementation that will not repeat the same value more than twice in a row. I leave that as an exercise :) As far as I can tell, "steady" is a misnomer. We can't guarantee that the timer will tick at a steady rate. That will depend on the quality of the hardware clock. -- Steven ___ 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
