Re: [Python-Dev] versioned .so files for Python 3.2

[Matthias Klose]

On 15.07.2010 01:59, Barry Warsaw wrote:

PEP 384 describes a change to ``PyModule_Create()`` where ``3`` is
passed as the API version if the extension was complied with
``Py_LIMITED_API``.  This should be formalized into an official macro
called ``PYTHON_ABI_VERSION`` to mirror ``PYTHON_API_VERSION``.  If
and when the ABI changes in an incompatible way, this version number
would be bumped.  To facilitate sharing, Python would be extended to
search for extension modules with the ``PYTHON_ABI_VERSION`` number in
its name.  The prefix ``abi`` is reserved for Python's use.

Thus for example, an initial implementation of PEP 384, compiled with
`--with-so-abi-tag=cpython-xy` would search for the following file
names when extension module `foo` is imported (in this order)::

 foo.abi3.so
 foo.cpython-xy.so
 foo.so

The distutils [7]_ ``build_ext`` command would also have to be
extended to compile to shared library files with the ``abi3`` tag,
when the module author indicates that their extension supports that
version of the ABI.  This could be done in a backward compatible way
by adding a keyword argument to the ``Extension`` class, such as::

 Extension('foo', ['foo.c'], abi=3)


I like the proposal, but IMO it is too unspecific about the abi tag.  Assume 
that an extension is built with such a configured python and then tried to run 
with an abi compatible configured python, but with a slightly different version 
tag, the extension won't be found.  Differing file names per configuration 
should be avoided. Proposing


  1) Remove the configure option and use the new naming using the tag for
 all configurations unconditionally.  Everybody can expect the same
 name on every installation, and PEP 384 most likely will require
 using a tag too.
 As Amaury did point out, there is a use case in that PyPy can use this
 tag too to build extensions only usable by PyPy.

  2) As PEP 3147 defines a non-configurable name for .pyc files, this PEP
 should define a non-configurable way for the tag. The tag should
 include all information which currently makes an extension ABI
 incompatible:
  - the python implementation (cpython, PyPy, ...)
  - the python version (3,2, 3.3, ...)
  - unicode configure option (--with-wide-unicode, 16 or 32)
  - platform information (necessary?)
 If this list changes for coming python versions, then it can be
 extended.
 Barry pointed out on irc chat that people might want to build
 experimental ABI incompatible versions, which should have its
 own tag. If this is wanted, please provide a configure option
 which lets extend/append to the tag.

  3) In case that 1) is not acceptable, the --with-so-abi-tag option
 should be implemented in such a way that it isn't required to
 take any arguments, and in this case to default to the fixed
 naming schema described in 2).

Matthias
___
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] versioned .so files for Python 3.2

[Daniel Stutzbach]

On Fri, Jul 16, 2010 at 5:40 AM, Matthias Klose  wrote:

>  2) As PEP 3147 defines a non-configurable name for .pyc files, this PEP
> should define a non-configurable way for the tag. The tag should
> include all information which currently makes an extension ABI
> incompatible:
>  - the python implementation (cpython, PyPy, ...)
>  - the python version (3,2, 3.3, ...)
>  - unicode configure option (--with-wide-unicode, 16 or 32)
>  - platform information (necessary?)


I'm not sure it's that easy to enumerate all of the ways to end up with an
incompatible ABI.  There are quite a lot of configure options listed with
"configure --help", and it's not always obvious if an option changes the
ABI.  On top of that, there are compilation flags that can change the ABI,
as Kristján discovered in the following thread:

http://mail.python.org/pipermail/python-dev/2010-June/100583.html

On the flip side, a fully enumerated ABI signature could be used to identify
(in)compatible binary eggs, which is basically impossible now.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] versioned .so files for Python 3.2

[Matthias Klose]

On 16.07.2010 15:43, Daniel Stutzbach wrote:

On Fri, Jul 16, 2010 at 5:40 AM, Matthias Klose  wrote:


  2) As PEP 3147 defines a non-configurable name for .pyc files, this PEP
 should define a non-configurable way for the tag. The tag should
 include all information which currently makes an extension ABI
 incompatible:
  - the python implementation (cpython, PyPy, ...)
  - the python version (3,2, 3.3, ...)
  - unicode configure option (--with-wide-unicode, 16 or 32)
  - platform information (necessary?)



I'm not sure it's that easy to enumerate all of the ways to end up with an
incompatible ABI.  There are quite a lot of configure options listed with
"configure --help", and it's not always obvious if an option changes the
ABI.  On top of that, there are compilation flags that can change the ABI,
as Kristján discovered in the following thread:


right, I forgot about the debug builds, because it's already the standard on 
windows to build foo_d.so extensions, and I adopted it for Debian/Ubuntu too.



On the flip side, a fully enumerated ABI signature could be used to identify
(in)compatible binary eggs, which is basically impossible now.


indeed.
___
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] New regex module for 3.2?

[Vlastimil Brom]

2010/7/9 Georg Brandl :
> Am 09.07.2010 02:35, schrieb MRAB:
>
>>
>> 1. Some of the inline flags are scoped; for example, putting "(?i)" at
>> the end of a regex will now have no effect because it's no longer a
>> global, all-or-nothing, flag.
>
> That is problematic.  I've often seen people put these flags at the end
> of a regex, probably for readability purposes.  IMHO it would be better
> to limit flag scoping to the explicit (?flags-flags: ) groups.
>

I just noticed the formulation on the reference page
regular-expressions.info on this kind of flags:
"(?i)   Turn on case insensitivity for the remainder of the regular
expression. (Older regex flavors may turn it on for the entire
regex.)" and likewise for other flags.

http://www.regular-expressions.info/refadv.html

I am not sure, how "authoritative" this page by Jan Goyvaerts is for
various implementations, but it looks like a very comprehensive
reference.
I think with a new regex implementation, not all of this "historical"
semantics must be copied, unless there are major real usecases, which
would be affected by this.
Just a thought;
Vlastimil Brom
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2010-07-09 - 2010-07-16)
Python tracker at http://bugs.python.org/

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


 2807 open (+44) / 18285 closed (+18) / 21092 total (+62)

Open issues with patches:  1144

Average duration of open issues: 703 days.
Median duration of open issues: 497 days.

Open Issues Breakdown
   open  2765 (+42)
languishing14 ( +0)
pending27 ( +2)

Issues Created Or Reopened (64)
___

regrtest: add a minimal "progress bar" 2010-07-10
   http://bugs.python.org/issue8560reopened georg.brandl
 
   patch   

contextlib.ContextDecorator2010-07-15
   http://bugs.python.org/issue9110reopened ncoghlan
 
   patch   

dict_keys purports to implement the Set ABC, but is missing th 2010-07-09
   http://bugs.python.org/issue9212created  stutzbach   
 
   

range purports to implement the Sequence ABC, but is missing i 2010-07-09
   http://bugs.python.org/issue9213created  stutzbach   
 
   

Most Set methods of KeysView and ItemsView do not work right   2010-07-09
   http://bugs.python.org/issue9214created  stutzbach   
 
   easy

test_float crashes with assertion failure on Ubuntu buildbot.  2010-07-09
CLOSED http://bugs.python.org/issue9215created  mark.dickinson  
 
   

FIPS support for hashlib   2010-07-10
   http://bugs.python.org/issue9216created  dmalcolm
 
   patch   

2to3 crashes with some doctests2010-07-14
   http://bugs.python.org/issue9217reopened tiagoantao  
 
   

pop multiple elements of a list at once2010-07-10
   http://bugs.python.org/issue9218created  jacobidiego 
 
   

Make reindent-rst.py preserve ^L   2010-07-10
CLOSED http://bugs.python.org/issue9219created  merwok  
 
   easy

Modules no longer usable as context managers   2010-07-10
CLOSED http://bugs.python.org/issue9220created  j1m 
 
   

2to3 fails to parse a for construct2010-07-10
CLOSED http://bugs.python.org/issue9221created  tiagoantao  
 
   

IDLE: Fix open/saveas 'Files of type' choices  2010-07-11
   http://bugs.python.org/issue9222created  tjreedy 
 
   patch, easy 

distutils Command docs linking 2010-07-11
CLOSED http://bugs.python.org/issue9223created  techtonik   
 
   

Distutls fails with MSVC++ 2008on Windows Vista 64bit  2010-07-11
CLOSED http://bugs.python.org/issue9224created  ipatrol 
 
   

Replace DUP_TOPX with DUP_TOP_TWO  2010-07-11
   http://bugs.python.org/issue9225created  serprex 
 
   patch   

erroneous behavior when creating classes inside a closure  2010-07-11
   http://bugs.python.org/issue9226created  monsanto
 
   patch   

can't import Tkinter / use IDLE after installing Python 2.7 on 2010-07-11
   http://bugs.python.org/issue9227created  michael.foord   
 
   

Make changes in the path and 

[Python-Dev] more details of list comprehension in tutorial than in language reference

[Peng Yu]

Hi,

Since this is related to the document, I think that I should send this
to the dev mailing list. Please let me know if this is not
appropriate.

If I don't miss anything, I feel that there are much less descriptions
of list comprehensions in the language reference
(python_2.6.5_reference.pdf, glossary) than in the tutorial
(python_2.6.5_tutorial.pdf). I think that it deserves at least a
subsection in the language reference to make the reference complete.
May I suggest the maintainer of the document add such a subsection?

-- 
Regards,
Peng
___
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] more details of list comprehension in tutorial than in language reference

[Michael Foord]

On 16/07/2010 17:32, Peng Yu wrote:

Hi,

Since this is related to the document, I think that I should send this
to the dev mailing list. Please let me know if this is not
appropriate.

If I don't miss anything, I feel that there are much less descriptions
of list comprehensions in the language reference
(python_2.6.5_reference.pdf, glossary) than in the tutorial
(python_2.6.5_tutorial.pdf). I think that it deserves at least a
subsection in the language reference to make the reference complete.
May I suggest the maintainer of the document add such a subsection?

   
If you would like to write an addition and post it to the Python bug 
tracker it would be (very) welcomed for consideration. The tutorial has 
no single "maintainer" but we are always looking to improve it.


All the best,

Michael Foord

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
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] New regex module for 3.2?

[Georg Brandl]

Am 16.07.2010 17:08, schrieb Vlastimil Brom:
> 2010/7/9 Georg Brandl :
>> Am 09.07.2010 02:35, schrieb MRAB:
>>
>>>
>>> 1. Some of the inline flags are scoped; for example, putting "(?i)" at
>>> the end of a regex will now have no effect because it's no longer a
>>> global, all-or-nothing, flag.
>>
>> That is problematic.  I've often seen people put these flags at the end
>> of a regex, probably for readability purposes.  IMHO it would be better
>> to limit flag scoping to the explicit (?flags-flags: ) groups.
>>
> 
> I just noticed the formulation on the reference page
> regular-expressions.info on this kind of flags:
> "(?i) Turn on case insensitivity for the remainder of the regular
> expression. (Older regex flavors may turn it on for the entire
> regex.)" and likewise for other flags.
> 
> http://www.regular-expressions.info/refadv.html
> 
> I am not sure, how "authoritative" this page by Jan Goyvaerts is for
> various implementations, but it looks like a very comprehensive
> reference.

Nevertheless, the authoritative reference for our regex engine is its
docs, i.e. http://docs.python.org/library/re.html -- and that states
clearly that inline flags apply to the whole regex.

> I think with a new regex implementation, not all of this "historical"
> semantics must be copied, unless there are major real usecases, which
> would be affected by this.

As I already said, I *have* seen this in real code.  As MRAB indicated,
this was the only silent change in semantics as compared to the old
regex engine.  If we replace re by regex, which I think is the only
way to get the new features in the stdlib, changing this one aspect is
a) not backwards compatible and b) in a subtle way that forces everyone
to review his/her regular expressions.  That's definitely not
acceptable.


Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] more details of list comprehension in tutorial than in language reference

[R. David Murray]

On Fri, 16 Jul 2010 11:32:25 -0500, Peng Yu  wrote:
> Since this is related to the document, I think that I should send this
> to the dev mailing list. Please let me know if this is not
> appropriate.

It is not, really.  Documentation issues should be posted as bugs
in the bug tracker under the 'Documentation' component.

> If I don't miss anything, I feel that there are much less descriptions
> of list comprehensions in the language reference
> (python_2.6.5_reference.pdf, glossary) than in the tutorial
> (python_2.6.5_tutorial.pdf). I think that it deserves at least a
> subsection in the language reference to make the reference complete.
> May I suggest the maintainer of the document add such a subsection?

The Language Reference is intentionally terse.  If there is important
syntactic/semantic information *missing* then it should be added, but if
it is just lacking in the detail of the explanations, then the tutorial
is the place for those, and you say that is OK.

--
R. David Murray  www.bitdance.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] importlib

[Antoine Pitrou]

On Wed, 14 Jul 2010 23:06:58 -0700
Brett Cannon  wrote:
> >
> > In any case, here my results under a Linux system:
> >
> > $ ./python -m importlib.test.benchmark
> > sys.modules [ 323782 326183 326667 ] best is 326667
> > Built-in module [ 33600 33693 33610 ] best is 33693
> >
> > $ ./python -m importlib.test.benchmark -b
> > sys.modules [ 1297640 1315366 1292283 ] best is 1315366
> > Built-in module [ 58180 57708 58057 ] best is 58180
> 
> And this is what might make evaluating importlib tough; while the
> performance is 25% of what it is for import.c, being able to import
> over 300,000 times/second is still damn fast.

Yes, that's very encouraging.
I guess the final test would be to take something like Mercurial, and
time e.g. "hg version" both with the builtin-import, and with importlib
enabled as default import mechanism.

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

[Brett Cannon]

I have updated the benchmark to now measure importing source w/o writing
bytecode, importing source & writing bytecode, and importing bytecode w/
source (as I don't care about sourceless import performance).

Now, before you look at these numbers, realize that I have not once tried to
profile importlib to see where its hot spots are (only optimization I have
done is cut down on the stat calls since Python 3.1 when I re-developed the
ABCs). I'm sure if I profiled the code and wrote key bits in C these
performance numbers would improve reasonably quickly.

Anyway, on my 2.2 GHz MacBook, this leads to::

import.c
sys.modules [ 223337 223036 223362 ] best is 223362
Built-in module [ 23347 23319 23331 ] best is 23347
Bytecode w/ source [ 6624 6607 6608 ] best is 6624
Source w/o bytecode [ 4643 4674 4655 ] best is 4674
Source writing bytecode [ 2063 2145 2204 ] best is 2204

importlib
sys.modules [ 43423 43414 43426 ] best is 43426
Built-in module [ 9130 9115 9120 ] best is 9130
Bytecode w/ source [ 1554 1556 1556 ] best is 1556
Source w/o bytecode [ 1351 1351 1353 ] best is 1353
Source writing bytecode [ 786 843 810 ] best is 843

importlib / import.c:
sys.modules  19%
Built-in module  39%
Bytecode w/ source  23%
Source w/o bytecode  29%
Source writing bytecode  38%

What does this show? Stuff that requires a lot of I/O has the smallest
performance difference (source writing bytecode), but where there is as
little I/O as possible (bytecode w/ source) import.c wins as it has to do
less. This is also why sys.modules is so damn fast; it's the smallest amount
of C code you can run while importlib has standard Python calling overhead.

It should also be pointed out that importlib has fully implemented PEP 302
and intentionally has the loaders using their own exposed PEP 302 APIs. This
means there are a lot more methods calls than in the C version, along with a
lot less corners cut in the name of performance. So while importlib will be
slower simply because it's implemented in C, it will also be slower because
the darn thing is actually written to follow the PEPs we have along with
making it easier for people to subclass and benefit from the import code.

Anyway, as I have said, I need to hit 100% compatibility when running the
test suite -- run importlib.test.regrtest to see where it fails now; also
read that file as it has notes as to why the known failures are happening --
before I start worrying about bootstrapping and performance and that will
all be no sooner than Python 3.3.

On Thu, Jul 15, 2010 at 04:55, Nick Coghlan  wrote:

> On Thu, Jul 15, 2010 at 4:06 PM, Brett Cannon  wrote:
> >> In any case, here my results under a Linux system:
> >>
> >> $ ./python -m importlib.test.benchmark
> >> sys.modules [ 323782 326183 326667 ] best is 326667
> >> Built-in module [ 33600 33693 33610 ] best is 33693
> >>
> >> $ ./python -m importlib.test.benchmark -b
> >> sys.modules [ 1297640 1315366 1292283 ] best is 1315366
> >> Built-in module [ 58180 57708 58057 ] best is 58180
> >
> > And this is what might make evaluating importlib tough; while the
> > performance is 25% of what it is for import.c, being able to import
> > over 300,000 times/second is still damn fast.
>
> Yeah, I think the numbers where the filesystem gets involved are going
> to be more relevant. Modules that have already been cached and those
> built in to the executable aren't likely to dominate interpreter and
> application startup times (which is the main thing I'm worried about
> seeing regress).
>
> 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] query: docstring formatting in python distutils code

[Terry Reedy]

On 7/7/2010 2:27 PM, Georg Brandl wrote:

Am 07.07.2010 19:53, schrieb Éric Araujo:

I promised to write a PEP about that some time in the future.  (Probably after
3.2 final.)



It seems that projects putting Sphinxy reST in their doc are using
automatic doc generation. This is however not always the best way to
make good doc, as demonstrated by Python’s hand-written,
very-high-quality documentation.



I know, and this is what I originally intended for Sphinx.  However, the calls
for automatic doc generation are very loud, and it's understandable that most
project can't afford writing their documentation twice.


Neither can CPython, really, as evidenced by numerous examples that have 
shone up on the tracker. Let me add another one. A week ago, Eli 
Benderdky asked me for help adding missing pieces to the trace module 
doc. The result so far is

http://bugs.python.org/issue9264

After getting that far, I noticed that there were already doc strings 
for some things that were not documented in the manual, which we added. 
I also noticed the the public methods already in the manual had not help 
strings, and hence no helpful help() output. In other words, the manual 
entries and doc strings were close to disjoint sets.


Even when they do overlap as they should, violation of DRY is a 
maintenance nightmare when anything changes. It would be better if the 
manual could, to some extent, be docstrings plus additions.


--
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] query: docstring formatting in python distutils code

[Georg Brandl]

Am 16.07.2010 22:55, schrieb Terry Reedy:
> On 7/7/2010 2:27 PM, Georg Brandl wrote:
>> Am 07.07.2010 19:53, schrieb Éric Araujo:
 I promised to write a PEP about that some time in the future.  (Probably 
 after
 3.2 final.)
> 
>>> It seems that projects putting Sphinxy reST in their doc are using
>>> automatic doc generation. This is however not always the best way to
>>> make good doc, as demonstrated by Python’s hand-written,
>>> very-high-quality documentation.
> 
>> I know, and this is what I originally intended for Sphinx.  However, the 
>> calls
>> for automatic doc generation are very loud, and it's understandable that most
>> project can't afford writing their documentation twice.
> 
> Neither can CPython, really, as evidenced by numerous examples that have 
> shone up on the tracker. Let me add another one. A week ago, Eli 
> Benderdky asked me for help adding missing pieces to the trace module 
> doc. The result so far is
> http://bugs.python.org/issue9264
> 
> After getting that far, I noticed that there were already doc strings 
> for some things that were not documented in the manual, which we added. 
> I also noticed the the public methods already in the manual had not help 
> strings, and hence no helpful help() output. In other words, the manual 
> entries and doc strings were close to disjoint sets.

And that's a pity -- very commendable that you work on this.  But this is
a single case, and most of our library is very well covered by the docs
and docstrings.  Additions (which usually are small amendments) are made
only in the docs, not the docstring, as it should be given the nature of
our docstrings.  Added functionality is usually documented first in
docstrings, which then get copied into the docs, and are padded from there.

> Even when they do overlap as they should, violation of DRY is a 
> maintenance nightmare when anything changes. It would be better if the 
> manual could, to some extent, be docstrings plus additions.

That sounds nice in theory, but opens another can of worms: what belongs
in the docstring, what in the "addition"?  How does it work for builtin
types, for language features, and so on.  Also, the problems I already
outlined in my answer to Fred remain...

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Curious datetime method

[Alexander Belopolsky]

I always thought that date.today() was a date class method and its
availability as a datetime method was an artifact of datetime
inheritance from date.  I thought datetime.today() would be just the
same as date.today().  It turned out I was wrong.  Instead,
datetime.today() is more like datetime.now().  Almost.

>>> datetime.today()
datetime.datetime(2010, 7, 16, 20, 5, 10, 710143)

The documentation says X.today() is equivalent to
X.fromtimestamp(time.time()) and this is literary true:

>>> class X(datetime):
... @classmethod
... def fromtimestamp(cls, t):
... return "whatever"
...

>>> X.today()
'whatever'

Unlike datetime.now() which gets time directly from OS,
datetime.today() calls time.time(), gets timestamp as float and breaks
it into integer datetime components in fromtimestamp().

This method is slow, relies on various poorly defined float to integer
conversions and cannot produce anything other than local time as a
naive datetime object.

I wonder why would anyone want to use datetime.today() instead of
datetime.now()?
___
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] A suggestion

[Brandon Hayden]

In the Python language, or any other language for that matter, I have  never 
understood why they don't have a loop function. Here's what I  mean, every time 
someone wants something to repeat itself, they have to  write a while loop like 
this:

x = 0
while x < 10:
function()
x = x + 1

When, instead of writing all of that, you could do something similar to  this:

function().10

Where you can just type in the number 10 right next to it. It makes no  since.


  ___
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] A suggestion

[Terry Reedy]

On 7/16/2010 10:38 PM, Brandon Hayden wrote:

In the Python language, or any other language for that matter, I have
never understood why they don't have a loop function. Here's what I
mean, every time someone wants something to repeat itself, they have to
write a while loop like this:

x = 0
while x < 10:
function()
x = x + 1

When, instead of writing all of that, you could do something similar to
this:

function().10

Where you can just type in the number 10 right next to it. It makes no
since.


Ask on python-list/clp/gmane.comp.python.general for an explanation.


--
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] A suggestion

[Alexander Belopolsky]

On Fri, Jul 16, 2010 at 10:38 PM, Brandon Hayden
 wrote:
> In the Python language, or any other language for that matter, ..

You brought this question to the wrong forum, but in Ruby you can do

>> 10.times{f}

to execute f 10 times.
___
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