Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

[Larry Hastings]

On 04/28/2012 04:20 PM, Eric V. Smith wrote:

But we generally use a namedtuple (or structseq) for things like
get_clock_info. For example, for sys.float_info there's no need for it
to be a tuple, and it can be extended in the future, yet it's a structseq.


I'd prefer an object to a dict, but not a tuple / structseq.  There's no 
need for the members to be iterable.



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

[Eric V. Smith]

On 4/29/2012 4:41 AM, Larry Hastings wrote:
> On 04/28/2012 04:20 PM, Eric V. Smith wrote:
>> But we generally use a namedtuple (or structseq) for things like
>> get_clock_info. For example, for sys.float_info there's no need for it
>> to be a tuple, and it can be extended in the future, yet it's a structseq.
> 
> I'd prefer an object to a dict, but not a tuple / structseq.  There's no
> need for the members to be iterable.

I agree with you, but there's already plenty of precedent for this. A
quick check shows sys.flags, sys.float_info, and os.stat(); I'm sure
there's more.

Iteration for these isn't very useful, but structseq is the handiest
type we have:

>>> for v in sys.float_info:
...   print(v)
...
1.79769313486e+308
1024
308
2.22507385851e-308
-1021
-307
15
53
2.22044604925e-16
2
1

For python code I use namedtuple (or my own recordtype), which are
iterable but almost no one iterates over them.

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

[Larry Hastings]

On 04/29/2012 02:01 AM, Eric V. Smith wrote:

On 4/29/2012 4:41 AM, Larry Hastings wrote:

I'd prefer an object to a dict, but not a tuple / structseq.  There's no
need for the members to be iterable.

I agree with you, but there's already plenty of precedent for this.
[...] Iteration for these isn't very useful, but structseq is the handiest
type we have:


The times, they are a-changin'.  I've been meaning to start whacking the 
things which are iterable which really shouldn't be.  Like, who uses 
destructuring assignment with the os.stat result anymore?  Puh-leez, 
that's so 1996.  That really oughta be deprecated.


Anyway, it'd be swell if we could stop adding new ones.  Maybe we need a 
clone of structseq that removes iterability?  (I was thinking, we could 
hack structseq so it didn't behave iterably if n_in_sequence was 0.  
But, no, it inherits from tuple, such shenanigans are a bad idea.)



//arry/

p.s. MvL gets credit for the original observation, and the suggestion of 
deprecating iterability.  As usual I'm standing on somebody else's 
shoulders.
___
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] package imports, sys.path and os.chdir()

[Christian Tismer]

On 28.04.12 21:16, Brett Cannon wrote:



On Sat, Apr 28, 2012 at 04:08, Nick Coghlan > wrote:


On Sat, Apr 28, 2012 at 6:00 AM, Brett Cannon mailto:br...@python.org>> wrote:
> I'm personally in favour of changing the insertion of '' to
sys.path to
> inserting the cwd when the interpreter is launched.

I'm not, because it breaks importing from the interactive prompt if
you change directory after starting the session.


Who does that? I mean what possible need do you have to start the 
interpreter in one directory, but then need to chdir somewhere else 
where you are doing your actual importing from, and in a way where you 
can't simply attach the directory you want to use into sys.path?




Well, it depends on which hat I'm wearing.

Scenario 1:
I am designing a big application. This application shall run without 
problems,

with disambiguated imports, and by no means should hit anything that is not
meant to be imported.
In this case, I need to remove '' from sys.path and replace it with an 
absolute entry.


Update: I see this works already unless "-c" and "-m" are present (hum).

Scenario 2:
I am playing with the application, want to try several modules, or even 
several versions
of modules. I do use os.chdir() to get into a certain context, try 
imports, remove them
again, chdir() to a different directory with a slightly changed module, 
et cetera.
In this case, I need '' (or as has been mentioned '.') to have 
flexibility for testing,

debugging and exploration.

These scenarios are both perfectly valid for their use case, but they 
have pretty

different implication for imports, and especially for sys.path.

So the real question I was after was "can os.chdir() be freely used?"

It would be great to get "yes" or "no", but the answer is right now "it 
depends".


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

[Steven D'Aprano]

Larry Hastings wrote:


On 04/29/2012 02:01 AM, Eric V. Smith wrote:

On 4/29/2012 4:41 AM, Larry Hastings wrote:

I'd prefer an object to a dict, but not a tuple / structseq.  There's no
need for the members to be iterable.

I agree with you, but there's already plenty of precedent for this.
[...] Iteration for these isn't very useful, but structseq is the 
handiest

type we have:


The times, they are a-changin'.  I've been meaning to start whacking the 
things which are iterable which really shouldn't be.  Like, who uses 
destructuring assignment with the os.stat result anymore?  Puh-leez, 
that's so 1996.  That really oughta be deprecated.


Why? What problems does it cause?

If it isn't broken, don't break it.



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

Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

[Antoine Pitrou]

On Sun, 29 Apr 2012 02:12:41 -0700
Larry Hastings  wrote:
> 
> On 04/29/2012 02:01 AM, Eric V. Smith wrote:
> > On 4/29/2012 4:41 AM, Larry Hastings wrote:
> >> I'd prefer an object to a dict, but not a tuple / structseq.  There's no
> >> need for the members to be iterable.
> > I agree with you, but there's already plenty of precedent for this.
> > [...] Iteration for these isn't very useful, but structseq is the handiest
> > type we have:
> 
> The times, they are a-changin'.  I've been meaning to start whacking the 
> things which are iterable which really shouldn't be.  Like, who uses 
> destructuring assignment with the os.stat result anymore?  Puh-leez, 
> that's so 1996.  That really oughta be deprecated.

Some types can benefit from being hashable and having a minimal
footprint (hence tuple-like). However it's not the case for
get_clock_info(), since you're unlikely to have more than one instance
alive in a given invokation.

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

[Antoine Pitrou]

On Sun, 29 Apr 2012 03:26:26 +0200
Victor Stinner  wrote:

> Hi Guido,
> 
> 2012/4/28 Guido van Rossum :
> > 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.
> 
> You're welcome, but many developers helped me!
> 
> > 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...
> 
> The PEP is not accepted yet at:
> http://www.python.org/dev/peps/pep-0418/
> 
> Did you forget to update its status, or are you waiting for something?
> 
> Anyway I commited the implementation of the PEP 418 (after the last
> change on the API of time.get_clock_info()). Let's see how buildbots
> feel with monotonic time.

Hopefully they'll be monotonously green!

cheers

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

[Christian Tismer]

On 29.04.12 07:05, Nick Coghlan wrote:

On Sun, Apr 29, 2012 at 1:41 PM, PJ Eby  wrote:

That's already the case.  Actually, sys.path[0] is *always* the absolute
path of the script directory -- regardless of whether you invoked the script
by a relative path or an absolute one, and regardless of whether you're
importing 'site' -- at least on Linux and Cygwin and WIndows, for all Python
versions I've used regularly, and 3.2 besides.

"-c" and "-m" also insert the empty string as sys.path[0] in order to
find local files. They could just as easily insert the full cwd
explicitly though, and, in fact, they arguably should. (I say
arguably, because changing this *would* be a backwards incompatible
change - there's no such issue with requiring __file__ to be
absolute).


As a note: I tried to find out where and when the empty string actually
got inserted into sys.path. Not very easy, had to run the C debugger
to understand that:

It happens in sysmodule.c

PyMain
PySys_SetArgv(argc-_PyOS_optind, argv+_PyOS_optind);

that calls

PySys_SetArgvEx(int argc, char **argv, int updatepath)

and the logic weather to use the empty string or a full path etc.
is deeply hidden in a C function as a side effect. Brr!

It would be much cleaner and easier if that stuff would be ignored
today and called a Python implementation, instead.

Is that in the plans to get rid of C for such stuff? I hope so :-)

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

[Guido van Rossum]

On Sun, Apr 29, 2012 at 5:29 AM, Steven D'Aprano  wrote:
> Larry Hastings wrote:
>>
>>
>> On 04/29/2012 02:01 AM, Eric V. Smith wrote:
>>>
>>> On 4/29/2012 4:41 AM, Larry Hastings wrote:

 I'd prefer an object to a dict, but not a tuple / structseq.  There's no
 need for the members to be iterable.
>>>
>>> I agree with you, but there's already plenty of precedent for this.
>>> [...] Iteration for these isn't very useful, but structseq is the
>>> handiest
>>> type we have:
>>
>>
>> The times, they are a-changin'.  I've been meaning to start whacking the
>> things which are iterable which really shouldn't be.  Like, who uses
>> destructuring assignment with the os.stat result anymore?  Puh-leez, that's
>> so 1996.  That really oughta be deprecated.
>
>
> Why? What problems does it cause?
>
> If it isn't broken, don't break it.

It's an anti-pattern. You basically have to look up or copy/paste the
order of the fields to get it right. And there are many fields in the
stats structure that can't be added to the sequence because of the
requirement not to break backwards compatibility with code that
expects a fixed number of fields (in 1996 we also didn't have *
unpacking :-). So you're getting a legacy-determined subset of the
values anyway.

Ditto for times; while the first 6 fields are easy (y/m/d h/m/s) the
three after that are just fluff (weekday and some tz related things
that I can never remember) and again there is important stuff missing
like finer precision and useful tz info.

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

[Guido van Rossum]

On Sat, Apr 28, 2012 at 6:26 PM, Victor Stinner
 wrote:
> Hi Guido,
>
> 2012/4/28 Guido van Rossum :
>> 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.
>
> You're welcome, but many developers helped me!

I tried to imply that in the next sentence. :-) Still, without your
push it would not have happened.

>> 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...
>
> The PEP is not accepted yet at:
> http://www.python.org/dev/peps/pep-0418/
>
> Did you forget to update its status, or are you waiting for something?

To get to a machine with a checkout. Done.

> Anyway I commited the implementation of the PEP 418 (after the last
> change on the API of time.get_clock_info()). Let's see how buildbots
> feel with monotonic time.

Awesome!

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

[Guido van Rossum]

On Sat, Apr 28, 2012 at 1:32 PM, Victor Stinner
 wrote:
>>> As a thin wrapper, adding it to the time module was pretty much
>>> uncontroversial, I think. The PEP proposes cross-platform
>>> functions with consistent semantics, which is where a discussion was
>>> needed.
>>
>> True, but does this mean clock_gettime and friends only exist on
>> POSIX? Shouldn't they be in the os or posix module then? I guess I'm
>> fine with either place but I don't know if enough thought was put into
>> the decision. Up until now the time module had only cross-platform
>> functions (even if clock()'s semantics vary widely).
>
> The os module is big enough. Low level networks functions are not in
> the os module, but in the socket module.

There are subtle other reasons for that (such as that on Windows,
socket file descriptors and os file descriptors are different things).

But I'm fine with leaving these in the time module.

> Not all functions of the time module are always available. For
> example, time.tzset() is not available on all platforms. Another
> example, the new time.monotonic() is not available on all platforms
> ;-)
>
> Oh, I forgot to mention that time.clock_*() functions are not always
> available in the doc.

Yeah, I think the docs can use some work Maybe from someone interested
in contributing to docs specifically? I don't want to make Victor
responsible for everything. But the new docs for the time module are a
but confusing due to the explosion of new functions and constants.
E.g. several descriptions use 'clk_id' without explaining it. Maybe a
separate subsection can be created for low-level and/or
platform-specific items, leaving the main time module to explain the
traditional functions and the new portable functions from PEP 418?

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

[Python-Dev] time.clock_info() field names

[Benjamin Peterson]

Hi,
I see PEP 418 gives time.clock_info() two boolean fields named
"is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
a bit ugly, and they could just be renamed "monotonic" and "adjusted".

Thoughts?

-- 
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] time.clock_info() field names

[Antoine Pitrou]

On Sun, 29 Apr 2012 19:25:16 -0400
Benjamin Peterson  wrote:
> Hi,
> I see PEP 418 gives time.clock_info() two boolean fields named
> "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
> a bit ugly, and they could just be renamed "monotonic" and "adjusted".
> 
> Thoughts?

Agreed.

cheers

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] time.clock_info() field names

[Jim J. Jewett]

In http://mail.python.org/pipermail/python-dev/2012-April/119134.html
Benjamin Peterson wrote:

> I see PEP 418 gives time.clock_info() two boolean fields named
> "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
> a bit ugly, and they could just be renamed "monotonic" and "adjusted".

I agree with monotonic, but I think it should be "adjustable".

To me, "adjusted" and "is_adjusted" both imply that an adjustment
has already been made; "adjustable" only implies that it is possible.

I do remember concerns (including Stephen J. Turnbull's
 )
that "adjustable" should imply at least a list of past adjustments,
and preferably a way to make an adjustment.

I just think that stating it is adjustable (without saying how, or
whether and when it already happened) is less wrong than claiming it
is already adjusted just in case it might have been.

-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] time.clock_info() field names

[Benjamin Peterson]

2012/4/29 Jim J. Jewett :
>
>
> In http://mail.python.org/pipermail/python-dev/2012-April/119134.html
> Benjamin Peterson wrote:
>
>> I see PEP 418 gives time.clock_info() two boolean fields named
>> "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
>> a bit ugly, and they could just be renamed "monotonic" and "adjusted".
>
> I agree with monotonic, but I think it should be "adjustable".

I don't really care, but I think "adjusted" is fine. As in "this clock
is adjusted (occasionally)".


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