Re: [Python-Dev] sys.implementation

2012-04-27 Thread Eric Snow 
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw  wrote:
> It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
> rationale section would be useful, at least.

  http://mail.python.org/pipermail/python-ideas/2012-April/014954.html

-eric
___
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] Changes in html.parser may cause breakage in client code

2012-04-27 Thread Guido van Rossum 
Someone should contact the Django folks. Alex Gaynor?

On Thursday, April 26, 2012, Ezio Melotti wrote:

> Hi,
>
> On 26/04/2012 22.10, Vinay Sajip wrote:
>
>> Following recent changes in html.parser, the Python 3 port of Django I'm
>> working
>> on has started failing while parsing HTML.
>>
>> The reason appears to be that Django uses some module-level data in
>> html.parser,
>> for example tagfind, which is a regular expression pattern. This has
>> changed
>> recently (Ezio changed it in ba4baaddac8d).
>>
>
> html.parser doesn't use any private _name, so I was considering part of
> the public API only the documented names.  Several methods are marked with
> an "# internal" comment, but that's not visible unless you go read the
> source code.
>
>  Now tagfind (and other such patterns) are not marked as private (though
>> not
>> documented), but should they be? The following script (tagfind.py):
>>
>> import html.parser as Parser
>>
>> data = ''
>>
>> m = Parser.tagfind.match(data, 1)
>> print('%r ->  %r' % (Parser.tagfind.pattern, data[1:m.end()]))
>>
>> gives different results on 3.2 and 3.3:
>>
>> $ python3.2 tagfind.py
>> '[a-zA-Z][-.a-zA-Z0-9:_]*' ->  'select'
>> $ python3.3 tagfind.py
>> '([a-zA-Z][-.a-zA-Z0-9:_]*)(?:**\\s|/(?!>))*' ->  'select'
>>
>> The trailing space later causes a mismatch with the end tag, and leads to
>> the
>> errors. Django's use of the tagfind pattern is in a subclass of
>> HTMLParser, in
>> an overridden parse_startag method.
>>
>
> Django shouldn't override parse_starttag (internal and undocumented), but
> just use handle_starttag (public and documented).
> I see two possible reasons why it's overriding parse_starttag:
>  1) Django is working around an HTMLParser bug.  In this case the bug
> could have been fixed (leading to the breakage of the now-useless
> workaround), and now you could be able to use the original parse_starttag
> and have the correct result.  If it is indeed working around a bug and the
> bug is still present, you should report it upstream.
>  2) Django is implementing an additional feature.  Depending on what
> exactly the code is doing you might want to open a new feature request on
> the bug tracker. For example the original parse_starttag sets a
> self.lasttag attribute with the correct name of the last tag parsed.  Note
> however that both parse_starttag and self.lasttag are internal and
> shouldn't be used directly (but lasttag could be exposed and documented if
> people really think that it's useful).
>
>  Do we need to indicate more strongly that data like tagfind are private?
>> Or has
>> the change introduced inadvertent breakage, requiring a fix in Python?
>>
>
> I'm not sure that reverting the regex, deprecate all the exposed internal
> names, and add/use internal _names instead is a good idea at this point.
>  This will cause more breakage, and it would require an extensive renaming.
>  I can add notes to the documentation/docstrings and specify what's private
> and what's not though.
> OTOH, if this specific fix is not released yet I can still do something to
> limit/avoid the breakage.
>
> Best Regards,
> Ezio Melotti
>
>  Regards,
>>
>> Vinay Sajip
>>
>>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>


-- 
--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] package imports, sys.path and os.chdir()

2012-04-27 Thread Christian Tismer 

On 27.04.12 02:39, Nick Coghlan wrote:

On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer  wrote:

No big deal and easy to work around, I just would like to understand why.

I don't like it either and want to change it, but I'm also not going
to mess with it until the importlib bootstrapping is fully integrated
and stable.

For the moment, there's a workaround in runpy to ensure at least
__main__.__file__ is always absolute (even when using the -m switch).
Longer term, I'd like to see __file__ and __path__ entries to be
guaranteed to be *always* absolutely, even when they're imported
relative to the current working directory.



Is there a recommendable way to fix this? I would like to tell people
what to do to make imports reliable. Either I put something into
the toplevel __init__ code, or I hack something into .pth or sitecustomize,
and then forget about this.

But I fear hacking __init__ is the only safe way that works without
a special python setup, which makes the whole reasoning rather
useless, because I can _not_ forget about this waah ;-)

cheers - chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
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] Summary of Python tracker Issues

2012-04-27 Thread Python tracker 

ACTIVITY SUMMARY (2012-04-20 - 2012-04-27)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3405 ( +9)
  closed 23056 (+41)
  total  26461 (+50)

Open issues with patches: 1446 


Issues opened (37)
==

#5057: Unicode-widthdependent   optimizationleads   to  
non-portable pyc
http://bugs.python.org/issue5057  reopened by arigo

#8767: Configure: Cannot disable unicode
http://bugs.python.org/issue8767  reopened by r.david.murray

#10142: Support for SEEK_HOLE/SEEK_DATA
http://bugs.python.org/issue10142  reopened by jcea

#13903: New shared-keys dictionary implementation
http://bugs.python.org/issue13903  reopened by Mark.Shannon

#14339: Optimizing bin, oct and hex
http://bugs.python.org/issue14339  reopened by loewis

#14635: telnetlib uses select instead of poll - limited to FD_SETSIZE 
http://bugs.python.org/issue14635  opened by gregory.p.smith

#14639: Different behavior for urllib2 in Python 2.7
http://bugs.python.org/issue14639  opened by Diego.Manenti.Martins

#14642: Fix importlib.h build rule to not depend on hg
http://bugs.python.org/issue14642  opened by brett.cannon

#14643: Security page out of date
http://bugs.python.org/issue14643  opened by pitrou

#14645: Generator does not translate linesep characters in certain cir
http://bugs.python.org/issue14645  opened by r.david.murray

#14646: Require loaders set __loader__ and __package__
http://bugs.python.org/issue14646  opened by brett.cannon

#14647: imp.reload() on a package leads to a segfault or a GC assertio
http://bugs.python.org/issue14647  opened by brett.cannon

#14649: doctest.DocTestSuite error misleading when module has no docst
http://bugs.python.org/issue14649  opened by cjerdonek

#14651: pysetup run cmd can't handle option values in the setup.cfg
http://bugs.python.org/issue14651  opened by shimizukawa

#14652: Better error messages for wsgiref validator failures
http://bugs.python.org/issue14652  opened by ssm

#14653: Improve mktime_tz to use calendar.timegm instead of time.mktim
http://bugs.python.org/issue14653  opened by mitar

#14654: More fast utf-8 decoding
http://bugs.python.org/issue14654  opened by storchaka

#14655: traceback module docs should show how to print/fomat an except
http://bugs.python.org/issue14655  opened by r.david.murray

#14656: Add a macro for unreachable code
http://bugs.python.org/issue14656  opened by benjamin.peterson

#14657: Avoid two importlib copies
http://bugs.python.org/issue14657  opened by pitrou

#14660: Implement PEP 420: Implicit Namespace Packages
http://bugs.python.org/issue14660  opened by eric.smith

#14662: shutil.move broken in 2.7.3 on OSX (chflags fails)
http://bugs.python.org/issue14662  opened by grobian

#14665: faulthandler prints tracebacks in reverse order
http://bugs.python.org/issue14665  opened by pitrou

#14666: test_sendall_interrupted hangs on FreeBSD with a zombi multipr
http://bugs.python.org/issue14666  opened by haypo

#14667: No IDLE
http://bugs.python.org/issue14667  opened by James.Lu

#14668: Document the path option in the Windows installer
http://bugs.python.org/issue14668  opened by brian.curtin

#14669: test_multiprocessing failure on OS X Tiger
http://bugs.python.org/issue14669  opened by pitrou

#14672: Windows installer: add desktop shortcut(s)
http://bugs.python.org/issue14672  opened by jdigital

#14673: add sys.implementation
http://bugs.python.org/issue14673  opened by eric.snow

#14674: Add link to RFC 4627 from json documentation
http://bugs.python.org/issue14674  opened by storchaka

#14675: make distutils.ccompiler.CCompiler an abstract class
http://bugs.python.org/issue14675  opened by ramchandra.apte

#14676: DeprecationWarning missing in default warning filters document
http://bugs.python.org/issue14676  opened by petere

#14678: Update zipimport to support importlib.invalidate_caches()
http://bugs.python.org/issue14678  opened by brett.cannon

#14679: Changes to html.parser break third-party code
http://bugs.python.org/issue14679  opened by vinay.sajip

#14680: pydoc with -w option does not work for a lot of help topics
http://bugs.python.org/issue14680  opened by gregor.hoch

#14682: Backport missing errnos to 2.7
http://bugs.python.org/issue14682  opened by hynek

#1065986: Fix pydoc crashing on unicode strings
http://bugs.python.org/issue1065986  reopened by r.david.murray



Most recent 15 issues with no replies (15)
==

#14680: pydoc with -w option does not work for a lot of help topics
http://bugs.python.org/issue14680

#14679: Changes to html.parser break third-party code
http://bugs.python.org/issue14679

#14676: DeprecationWarning missing in default warning filters document
http://bugs.python.org/issue14676

#14674: Add link to RFC 4627 from json documentation
http://bugs.python.org/issue14674

#14652: Better error messages

Re: [Python-Dev] Changes in html.parser may cause breakage in client code

2012-04-27 Thread Terry Reedy 

On 4/27/2012 1:23 AM, Ezio Melotti wrote:


html.parser doesn't use any private _name, so I was considering part of
the public API only the documented names. Several methods are marked
with an "# internal" comment, but that's not visible unless you go read
the source code.


I could not find __all__ defined. Perhaps defining that would help.

--
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] sys.implementation

2012-04-27 Thread Glenn Linderman 

On 4/27/2012 12:34 AM, Eric Snow wrote:

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw  wrote:

It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
rationale section would be useful, at least.

   http://mail.python.org/pipermail/python-ideas/2012-April/014954.html


The idea of having separate versions for CPython and stdlib has been 
raised recently, although I believe it has been mostly been deferred or 
discarded.  Should that be resurrected, sys.implementation may be a good 
repository for the additional version info defining the stdlib version.


However, this PEP raises the following question in my mind: is the sys 
module part of the stdlib? Before reaching a hasty conclusion, consider 
the following points:


1) with this proposal, the contents of sys.implementation will vary 
between implementations.  If stdlib is to be shared among 
implementations, then it seems sys.implementation should not be part of 
the stdlib, but rather part of the implementation. Is sys considered 
part of the implementation or part of the stdlib? I've always perceived 
it as part of the stdlib, because of the way it is documented.


2) importlib wants to be part of the stdlib, and thus available to other 
implementations, but it must be built-in or frozen. The goal with 
importlib is a common implementation in Python, that can be used by all 
implementations.  I am not clear on whether the accelerated C code is 
part of the stdlib, or part of an implementation optimization, nor how 
the structuring of such things is arranged to separate stdlib from 
implementation (if it is; if it isn't, should it be?)


3) can anything that must be built-in or frozen be part of the stdlib? I 
don't see why not, if it is common to all implementations, even if it 
depends on data it obtains from the implementation via some mechanism 
such as the proposed sys.implementation. However, if it is not common, I 
don't know how it can be standard/stdlib... which raises issues in my 
understanding of the various modules available as Python with C 
accelerators, and I know there are pure C modules that are part of the 
stdlib. So I think this idea of making the stdlib more sharable between 
implementations is still a work-in-progress, even a design-in-progress, 
but maybe part of the solution is to separate, or at least delineate, 
things that can be common, from things that cannot be common to all 
implementations.


My conclusion is that sys.implementation clearly should not be part of 
the stdlib, but rather be part of the language implementation.  Whether 
it then fits with the rest of what is in sys, or not, I am not qualified 
to say.  If not, perhaps a new module name is warranted... perhaps 
"implementation" at the top level of the namespace.


So my thoughts are:

Things that are part of the stdlib should be available in Python source 
to be shared across implementations.  Things that are not available in 
Python source cannot be shared across implementations, and therefore 
should not be part of the stdlib, but rather part of an 
implementation-specific library, or part of the language specification.


Or maybe stdlib should be an umbrella term, with the following subsets: 
common (Python implementation available, and not dependent on 
implementation-specific details except in very standardized ways), 
implementation-specific (provided by each implementation, either in 
implementation-specific Python, or some other implementation language), 
accelerators (a faster version of a common module, provided by an 
implementation when necessary for performance).


In this situation, sys.implementation, as proposed, should be 
implementation-specific.


___
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] sys.implementation

2012-04-27 Thread R. David Murray 
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman  
wrote:
> On 4/27/2012 12:34 AM, Eric Snow wrote:
> > On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw  wrote:
> >> It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
> >> rationale section would be useful, at least.
> >http://mail.python.org/pipermail/python-ideas/2012-April/014954.html
> 
> My conclusion is that sys.implementation clearly should not be part of 
> the stdlib, but rather be part of the language implementation.  Whether 
> it then fits with the rest of what is in sys, or not, I am not qualified 
> to say.  If not, perhaps a new module name is warranted... perhaps 
> "implementation" at the top level of the namespace.

IMO, there are two different things here that you are conflating(*): the
*implementation* of the stdlib, and the stdlib *API*.  sys.implementation
would be a part of the API that any conforming implementation of
python+stdlib would be required to implement.

We also have a goal of making as much of the *implementation* of the
stdlib usable by any python implementation as possible, but as you say
that is a work in progress.

There are, by the way, many things documented in the "library"
documentation that are in fact provided by the language implementation
itself.  All of the fundamental types, for example.

--David

(*) the Oracle lawyers sometimes seem to be trying to get
the judge and jury to make the same mistake.
___
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] package imports, sys.path and os.chdir()

2012-04-27 Thread Brett Cannon 
On Fri, Apr 27, 2012 at 10:39, Christian Tismer wrote:

> On 27.04.12 02:39, Nick Coghlan wrote:
>
>> On Fri, Apr 27, 2012 at 7:30 AM, Christian Tismer
>>  wrote:
>>
>>> No big deal and easy to work around, I just would like to understand why.
>>>
>> I don't like it either and want to change it, but I'm also not going
>> to mess with it until the importlib bootstrapping is fully integrated
>> and stable.
>>
>> For the moment, there's a workaround in runpy to ensure at least
>> __main__.__file__ is always absolute (even when using the -m switch).
>> Longer term, I'd like to see __file__ and __path__ entries to be
>> guaranteed to be *always* absolutely, even when they're imported
>> relative to the current working directory.
>>
>>
> Is there a recommendable way to fix this? I would like to tell people
> what to do to make imports reliable. Either I put something into
> the toplevel __init__ code, or I hack something into .pth or sitecustomize,
> and then forget about this.
>
>
No, there isn't.


> But I fear hacking __init__ is the only safe way that works without
> a special python setup, which makes the whole reasoning rather
> useless, because I can _not_ forget about this waah ;-)
>

Yeah, to guarantee the semantics you are after you have to grab that ''
entry in sys.path as early as possible and substitute it with the cwd so
that its initial value propagates through the interpreter. Importlib is
already having to jump through some hoops to treat it as '.' and even that
doesn't get you what you want since that will change when the cwd is moved.

I'm personally in favour of changing the insertion of '' to sys.path to
inserting the cwd when the interpreter is launched.
___
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] sys.implementation

2012-04-27 Thread Glenn Linderman 

On 4/27/2012 11:49 AM, R. David Murray wrote:

On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman  
wrote:

On 4/27/2012 12:34 AM, Eric Snow wrote:

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw   wrote:

It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
rationale section would be useful, at least.

http://mail.python.org/pipermail/python-ideas/2012-April/014954.html

My conclusion is that sys.implementation clearly should not be part of
the stdlib, but rather be part of the language implementation.  Whether
it then fits with the rest of what is in sys, or not, I am not qualified
to say.  If not, perhaps a new module name is warranted... perhaps
"implementation" at the top level of the namespace.

IMO, there are two different things here that you are conflating(*): the
*implementation* of the stdlib, and the stdlib *API*.  sys.implementation
would be a part of the API that any conforming implementation of
python+stdlib would be required to implement.


Hmm.  OK.


We also have a goal of making as much of the *implementation* of the
stdlib usable by any python implementation as possible, but as you say
that is a work in progress.


OK.

There are, by the way, many things documented in the "library"
documentation that are in fact provided by the language implementation
itself.  All of the fundamental types, for example.


I was aware of this last, but wasn't thinking about it during these 
musings... although the thoughts of documentation also crossed my mind, 
I didn't mention them, figuring it could come up later.


So "library" documentation already covers all three categories of stuff 
that I mentioned, plus one more (restated here for clarity, with better 
wording):


* language implementation
* implementation dependent modules
* implementation independent modules
* implementation dependent optimizations of implementation independent 
modules


From the perspective of a user of a single implementation of the 
language + library, it really doesn't matter how the documentation is 
organized, or whether the documentation notes which of the above 4 
categories an item falls in.


From the perspective of a user of multiple implementations, or 
perspective of a developer of an implementation other than CPython, 
knowledge of the category could be useful for both portability and 
performance planning. Organizing the documentation in some manner to be 
aware of such categories may help other implementations provide 
appropriate addenda.  The closer any of them get to tracking the Py3 
trunk in real time, the more so.


Here's a ponderable: In the long term, should the documentation be 
unified for multiple implementations?  Or should it be split into 4 
pieces, so that alternate implementations could swap in their own 
sections for implementation dependent items?




--David

(*) the Oracle lawyers sometimes seem to be trying to get
the judge and jury to make the same mistake.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com




___
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] package imports, sys.path and os.chdir()

2012-04-27 Thread Glenn Linderman 

On 4/27/2012 1:00 PM, Brett Cannon wrote:
I'm personally in favour of changing the insertion of '' to sys.path 
to inserting the cwd when the interpreter is launched.

+1
___
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] package imports, sys.path and os.chdir()

2012-04-27 Thread Christian Tismer 

On 27.04.12 22:00, Brett Cannon wrote:



On Fri, Apr 27, 2012 at 10:39, Christian Tismer > wrote:


On 27.04.12 02:39, Nick Coghlan wrote:

On Fri, Apr 27, 2012 at 7:30 AM, Christian
Tismermailto:[email protected]>>  wrote:

No big deal and easy to work around, I just would like to
understand why.

I don't like it either and want to change it, but I'm also not
going
to mess with it until the importlib bootstrapping is fully
integrated
and stable.

For the moment, there's a workaround in runpy to ensure at least
__main__.__file__ is always absolute (even when using the -m
switch).
Longer term, I'd like to see __file__ and __path__ entries to be
guaranteed to be *always* absolutely, even when they're imported
relative to the current working directory.


Is there a recommendable way to fix this? I would like to tell people
what to do to make imports reliable. Either I put something into
the toplevel __init__ code, or I hack something into .pth or
sitecustomize,
and then forget about this.


No, there isn't.

But I fear hacking __init__ is the only safe way that works without
a special python setup, which makes the whole reasoning rather
useless, because I can _not_ forget about this waah ;-)


Yeah, to guarantee the semantics you are after you have to grab that 
'' entry in sys.path as early as possible and substitute it with the 
cwd so that its initial value propagates through the interpreter. 
Importlib is already having to jump through some hoops to treat it as 
'.' and even that doesn't get you what you want since that will change 
when the cwd is moved.


I'm personally in favour of changing the insertion of '' to sys.path 
to inserting the cwd when the interpreter is launched.


Thanks Brett, that sounds pretty reasonable. '' always was too implicit 
for me.


cheers - chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
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] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

2012-04-27 Thread Guido van Rossum 
Hi Victor,

I read most of the PEP and I think it is ready for acceptance! Thanks
for your patience in shepherding this through such a difficult and
long discussion. Also thanks to the many other contributors,
especially those who ended up as co-authors. We will have an awesome
new set of time APIs! Now let the implementation roll...

--Guido

On Mon, Apr 23, 2012 at 4:30 PM, Victor Stinner
 wrote:
>> Here is a simplified version of the first draft of the PEP 418. The
>> full version can be read online.
>> http://www.python.org/dev/peps/pep-0418/
>
> Thanks to everyone who helped me to work on this PEP!
>
> I integrated last comments. There is no more open question. (Or did I
> miss something?)
>
> I didn't know that it would be so hard to add a such simple function
> as time.monotonic()!?
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--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] Changes in html.parser may cause breakage in client code

2012-04-27 Thread Carl Meyer 

On 04/27/2012 08:36 AM, Guido van Rossum wrote:

Someone should contact the Django folks. Alex Gaynor?


I committed the relevant code to Django (though I didn't write the 
patch), and I've been following this thread. I have it on my todo list 
to review this code again with Ezio's suggestions in mind. So you can 
consider "the Django folks" contacted.


Carl
___
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] Changes in html.parser may cause breakage in client code

2012-04-27 Thread Guido van Rossum 
Awesome!

On Fri, Apr 27, 2012 at 3:07 PM, Carl Meyer  wrote:
> On 04/27/2012 08:36 AM, Guido van Rossum wrote:
>>
>> Someone should contact the Django folks. Alex Gaynor?
>
>
> I committed the relevant code to Django (though I didn't write the patch),
> and I've been following this thread. I have it on my todo list to review
> this code again with Ezio's suggestions in mind. So you can consider "the
> Django folks" contacted.
>
> Carl
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--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] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

2012-04-27 Thread Steven D'Aprano 

Some issues with the PEP 418:


1) time.clock is deprecated, but also supported by get_clock_info. Why bother 
supporting it if you don't want people to use it?



2) get_clock_info returns a dict. Why not a namedtuple?


3) The dict returned by get_clock_info includes an optional key, 
"is_adjusted". Why is it optional?



4) The section on mach_absolute_time states:

   According to the documentation (Technical Q&A QA1398), mach_timebase_info()
   is always equal to one and never fails, even if the function may fail
   according to its prototype.

I've read the linked technical note and I can't see anything about it always 
being equal to one. I don't think your description is accurate.



5) In the glossary, you mark some terms in angle brackets <> but there is no 
definition for them:


  
  
   (which I think should be  instead)


6) A stylistic suggestion: the glossary entries for Accuracy and Precision 
should each say "Contrast " and link to the Wikipedia article.



7) There is a mismatch in tenses between "Adjusted" and "Resetting" in the 
glossary. Suggest something like this instead:


Adjusted: Reset to the correct time. This may be done either
with a  or by .


8) The glossary defines steady as high stability and "relatively high accuracy
   and precision". But surely that is not correct -- a clock that ticks every
   once per second (low precision) is still steady.


9) The perf_counter pseudocode seems a bit unusual (unPythonic?) to me. Rather 
than checking flags at call-time, could you not use different function 
definitions at compile time?



10) The "Alternatives" section should list arguments made for and against the 
alternative APIs, not just list them.



Thanks for your excellent work Victor!



--
Steven
___
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] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

2012-04-27 Thread Victor Stinner 
> 1) time.clock is deprecated, but also supported by get_clock_info. Why
> bother supporting it if you don't want people to use it?

It will not be removed before Python 4, the function is still used by
Python < 3.3.

> 2) get_clock_info returns a dict. Why not a namedtuple?

I don't like the tuple API. I prefer a dict over a (named)tuple
because there is an optional key, and we migh add other optional keys
later.

> 3) The dict returned by get_clock_info includes an optional key,
> "is_adjusted". Why is it optional?

The value is not know for some platforms for some clock. I don't know
if process/thread time can be set for example. Sometimes the value is
hardcoded, sometimes the flag comes from the OS (ex: on Windows).

> 4) The section on mach_absolute_time states:
>
>   According to the documentation (Technical Q&A QA1398),
> mach_timebase_info()
>   is always equal to one and never fails, even if the function may fail
>   according to its prototype.
>
> I've read the linked technical note and I can't see anything about it always
> being equal to one. I don't think your description is accurate.

I don't remember where it does come from. I removed the sentence.

> 9) The perf_counter pseudocode seems a bit unusual (unPythonic?) to me.
> Rather than checking flags at call-time, could you not use different
> function definitions at compile time?

It's just a pseudo-code. I prefer to avoid duplication of code. The
pseudo-code is based on the C implemenation which use #ifdef;

Victor
___
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] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

2012-04-27 Thread Guido van Rossum 
On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano  wrote:
> Some issues with the PEP 418:
>
>
> 1) time.clock is deprecated, but also supported by get_clock_info. Why
> bother supporting it if you don't want people to use it?

I see the deprecation of clock() as mostly symbolic -- it's used way
too much to do anything about it (as the PEP acknowledges). So I think
it's reasonable we should return info about it.

> 2) get_clock_info returns a dict. Why not a namedtuple?

Future flexibility. And there's no need for it to be a *tuple*.

> 3) The dict returned by get_clock_info includes an optional key,
> "is_adjusted". Why is it optional?

I wondered that myself, but I suspect it means "we don't know".

> 4) The section on mach_absolute_time states:
>
>   According to the documentation (Technical Q&A QA1398),
> mach_timebase_info()
>   is always equal to one and never fails, even if the function may fail
>   according to its prototype.
>
> I've read the linked technical note and I can't see anything about it always
> being equal to one. I don't think your description is accurate.

Ok, you & Victor will have to figure that one out.

> 5) In the glossary, you mark some terms in angle brackets <> but there is no
> definition for them:
>
>  
>  
>   (which I think should be  instead)
>
>
> 6) A stylistic suggestion: the glossary entries for Accuracy and Precision
> should each say "Contrast " and link to the Wikipedia article.
>
>
> 7) There is a mismatch in tenses between "Adjusted" and "Resetting" in the
> glossary. Suggest something like this instead:
>
>    Adjusted: Reset to the correct time. This may be done either
>    with a  or by .
>
>
> 8) The glossary defines steady as high stability and "relatively high
> accuracy
>   and precision". But surely that is not correct -- a clock that ticks every
>   once per second (low precision) is still steady.
>
>
> 9) The perf_counter pseudocode seems a bit unusual (unPythonic?) to me.
> Rather than checking flags at call-time, could you not use different
> function definitions at compile time?
>
>
> 10) The "Alternatives" section should list arguments made for and against
> the alternative APIs, not just list them.
>
>
> Thanks for your excellent work Victor!

Surely those are all very minor quibbles. I have one myself: at some
point it says:

On Linux, it is possible to use time.clock_gettime(CLOCK_THREAD_CPUTIME_ID).

But the PEP doesn't define a function by that name. Is it an editing
glitch? (Some of the pseudo code also uses this.)

-- 
--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