Re: [Python-Dev] what is happening with the regex module going into Python 3.3?

[Martin v. Löwis]

On 04.06.2012 01:28, Nick Coghlan wrote:

I apologise, "unmaintained" is too strong a word. I mean "lacking an
owner sufficiently confident in their authority and expertise and with
sufficient time and energy to add,or approve the addition of,
substantial new features which may require significant refactoring of
internal details".

Perhaps "unowned" would be a better word? Saying yes or no to major
feature requests isn't the same as fixing errors in existing features.
(Compare regular email package maintenance to RDM's recent updates)


I see the same risk for regex. Maybe somebody steps forward and 
integrates the code, but I doubt that someone would then "own" the

code in the sense you refer to, i.e. decide on major new features, or
perform a significant internal refactoring. It would all be up to
MRAB.

Also, there is a chance that a maintainer for SRE may come back.
Gustavo Niemeyer had that role for some time after /F left, and
anybody sufficiently interested in a specific new feature might
grow into that role as well.

Regards,
Martin
___
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] What should we do with cProfile?

[Martin v. Löwis]

So I wondering whether we should abandon the change all together or
attempt it for the next release. Personally, I slightly leaning on
the former option since the two modules are actually fairly different
underneath even though they are used similarly. And also, because it
is getting late to make such backward incompatible changes.


I agree that this change is not worthwhile for Python 3. I suggest to
close the issue as "won't fix".

I'm not sure whether anybody uses the profile module at all, so
recycling the name might have been appropriate for Python 3.0. But
now that would be a backwards-incompatible change, and I agree it's
doubtful whether a backwards-compatible change can be achieved.

Even if profile could somehow stay compatible, nothing is gained if
cProfile also stays - but it would have to, for backwards compatibility
reasons.

I predict that at some point, somebody contributes yet another profiling
tool which may well supersede both profile and cProfile. If you are
interested in profiling in general, I suggest that you could rather work
on such code, and release it to PyPI.

Regards,
Martin
___
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] AUTO: Jon K Peck is out of the office (returning 06/06/2012)

[Jon K Peck]

I am out of the office until 06/06/2012.

I will be out of the office Monday and Tuesday, June 4-5.  I expect to have
some email access but may be delayed in responding.


Note: This is an automated response to your message  "Python-Dev Digest,
Vol 107, Issue 9" sent on 06/04/2012 0:19:23.

This is the only notification you will receive while this person is away.___
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 2736: datetimes and Unix timestamps

[Dirkjan Ochtman]

I recently opened issue14908. At work, I have to do a bunch of things
with dates, times and timezones, and sometimes Unix timestamps are
also involved (largely for easy compatibility with legacy APIs). I
find the relative obscurity when converting datetimes to timestamps
rather painful; IMO it should be possible to do everything I need
straight from the datetime module objects, instead of having to
involve the time or calendar modules.

Anyway, I was pointed to issue 2736, which seems to have got a lot of
discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
name just a few) up against Alexander (the datetime maintainer,
AFAIK). It seems like a fairly straightforward case of practicality
over purity: Alexander argues that there are "easy" one-liners to do
things like datetime.totimestamp(), but most other people seem to not
find them so easy. They've since been added to the documentation at
least, but I would like to see if there is consensus on python-dev
that adding a little more timestamp support to datetime objects would
make sense.

I hope this won't become another epic issue like the last time-related issue...

Cheers,

Dirkjan
___
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] Issue 2736: datetimes and Unix timestamps

[Nick Coghlan]

On Mon, Jun 4, 2012 at 9:19 PM, Dirkjan Ochtman  wrote:
> Anyway, I was pointed to issue 2736, which seems to have got a lot of
> discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
> name just a few) up against Alexander (the datetime maintainer,
> AFAIK). It seems like a fairly straightforward case of practicality
> over purity: Alexander argues that there are "easy" one-liners to do
> things like datetime.totimestamp(), but most other people seem to not
> find them so easy. They've since been added to the documentation at
> least, but I would like to see if there is consensus on python-dev
> that adding a little more timestamp support to datetime objects would
> make sense.
>
> I hope this won't become another epic issue like the last time-related 
> issue...

My perspective is that if I'm dealing with strictly absolute time, I
should only need one import: datetime

If I'm dealing strictly with relative time, I should also only need
one import: time

I shouldn't need to import any other modules to convert betwen them
and, since datetime is the higher level of the two, that's where the
responsibility for handling any conversions should lie.

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] Issue 2736: datetimes and Unix timestamps

[Dirkjan Ochtman]

On Mon, Jun 4, 2012 at 2:11 PM, Nick Coghlan  wrote:
> My perspective is that if I'm dealing with strictly absolute time, I
> should only need one import: datetime
>
> If I'm dealing strictly with relative time, I should also only need
> one import: time

Can you define "relative time" here? The term makes me think of things
like timedelta.

Personally, I would really like not having to think about the time
module at all, except if I wanted to go low-level (e.g. get a Unix
timestamp from scratch).

Cheers,

Dirkjan
___
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] Issue 2736: datetimes and Unix timestamps

[Nick Coghlan]

On Mon, Jun 4, 2012 at 10:18 PM, Dirkjan Ochtman  wrote:
> Can you define "relative time" here? The term makes me think of things
> like timedelta.

Timeouts, performance measurement, that kind of thing. Mostly
timescales of less than an hour, and usually less than a minute.

> Personally, I would really like not having to think about the time
> module at all, except if I wanted to go low-level (e.g. get a Unix
> timestamp from scratch).

Yup, that's what I meant, too.

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 405 (built-in virtualenv) status

[Carl Meyer]

Hello Christian,

On 06/03/2012 03:56 PM, Éric Araujo wrote:
> Le 02/06/2012 12:59, Christian Tismer a écrit :
>> One urgent question: will this feature be backported to Python 2.7?
> 
> Features are never backported to the stable versions.  virtualenv still
> exists as a standalone project which is compatible with 2.7 though.

To add to Éric's answer: the key difference between virtualenv and
pyvenv, allowing pyvenv environments to be much simpler, relies on a
change to the interpreter itself. This won't be backported to 2.7, and
can't be released as a standalone package.

It would be possible to backport the Python API and command-line UI of
pyvenv (which are different from virtualenv) as a PyPI package
compatible with Python 2.7. Because it wouldn't have the interpreter
change, it would have to still create environments that look like
virtualenv environments (i.e. they'd have to have chunks of the stdlib
symlinked in and a custom site.py). I suppose this could be useful if
wanting to script creation of venvs across Python 2 and Python 3, but
the utility seems limited enough that I have no plans to do this.

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

Re: [Python-Dev] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

[Brett Cannon]

[Let's try this again since my last reply was rejected for being too large]

On Mon, Jun 4, 2012 at 9:52 AM, barry.warsaw 
 wrote:

> http://hg.python.org/cpython/rev/9c445f4695c1
> changeset:   77339:9c445f4695c1
> parent:  77328:0808cb8c60fd
> user:Barry Warsaw 
> date:Sun Jun 03 16:18:47 2012 -0400
> summary:
>  Eric Snow's implementation of PEP 421.
>
> Issue 14673: Add sys.implementation
>
> files:
>  Doc/library/sys.rst   |   38 
>  Doc/library/types.rst |   24 ++
>  Include/Python.h  |1 +
>  Include/namespaceobject.h |   17 +
>  Lib/test/test_sys.py  |   18 ++
>  Lib/test/test_types.py|  143 -
>  Lib/types.py  |1 +
>  Makefile.pre.in    |2 +
>  Objects/namespaceobject.c |  225 ++
>  Objects/object.c  |3 +
>  Python/sysmodule.c|   72 -
>  11 files changed, 541 insertions(+), 3 deletions(-)
>
>
> diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
> --- a/Doc/library/sys.rst
> +++ b/Doc/library/sys.rst
> @@ -616,6 +616,44 @@
>
>Thus ``2.1.0a3`` is hexversion ``0x020100a3``.
>
> +
> +.. data:: implementation
> +
> +   An object containing the information about the implementation of the
> +   currently running Python interpreter.  Its attributes are the those
>

"the those" -> "those"


> +   that all Python implementations must implement.


Should you mention that VMs are allowed to add their own attributes that
are not listed?


>  They are described
> +   below.
> +
> +   *name* is the implementation's identifier, like ``'cpython'``.
>

Is this guaranteed to be lowercase, or does it simply happen to be
lowercase in this instance?


> +
> +   *version* is a named tuple, in the same format as
> +   :data:`sys.version_info`.  It represents the version of the Python
> +   *implementation*.  This has a distinct meaning from the specific
> +   version of the Python *language* to which the currently running
> +   interpreter conforms, which ``sys.version_info`` represents.  For
> +   example, for PyPy 1.8 ``sys.implementation.version`` might be
> +   ``sys.version_info(1, 8, 0, 'final', 0)``, whereas ``sys.version_info``
> +   would be ``sys.version_info(1, 8, 0, 'final', 0)``.


I think you meant to say ``sys.version_info(2, 7, 2, 'final', 0)``.
 What's with the ~?

-Brett
___
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: Eric Snow's implementation of PEP 421.

[Barry Warsaw]

Thanks for the second set of eyes, Brett.

On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote:

>> +.. data:: implementation
>> +
>> +   An object containing the information about the implementation of the
>> +   currently running Python interpreter.  Its attributes are the those
>>
>
>"the those" -> "those"

I actually rewrote this section a bit:

   An object containing information about the implementation of the
   currently running Python interpreter.  The following attributes are
   required to exist in all Python implementations.

>> +   that all Python implementations must implement.
>
>Should you mention that VMs are allowed to add their own attributes that
>are not listed?

Here's how I rewrote it:

   :data:`sys.implementation` may contain additional attributes specific to
   the Python implementation.  These non-standard attributes must start with
   an underscore, and are not described here.  Regardless of its contents,
   :data:`sys.implementation` will not change during a run of the interpreter,
   nor between implementation versions.  (It may change between Python
   language versions, however.)  See `PEP 421` for more information.

>>  They are described
>> +   below.
>> +
>> +   *name* is the implementation's identifier, like ``'cpython'``.
>
>Is this guaranteed to be lowercase, or does it simply happen to be
>lowercase in this instance?

Yes, PEP 421 guarantees them to be lower cased.

   *name* is the implementation's identifier, e.g. ``'cpython'``.  The actual
   string is defined by the Python implementation, but it is guaranteed to be
   lower case.

>I think you meant to say ``sys.version_info(2, 7, 2, 'final', 0)``.

Fixed.

>> +   However, for a structured record type use
>> :func:`~collections.namedtuple`
>>
>
>What's with the ~?

I'm not sure, but it seems to result in a cross-reference, and I see tildes
used elsewhere, so I guess it's some reST/docutils magic.  I left this one in
there.

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] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

[Michael Foord]

On 4 Jun 2012, at 16:10, Barry Warsaw wrote:

> [snip...]
>>> +   However, for a structured record type use
>>> :func:`~collections.namedtuple`
>>> 
>> 
>> What's with the ~?
> 
> I'm not sure, but it seems to result in a cross-reference, and I see tildes
> used elsewhere, so I guess it's some reST/docutils magic.  I left this one in
> there.
> 


It means display the link with the text "namedtuple" instead of the full 
"collections.namedtuple". You can't just omit the "collections" as Sphinx needs 
to know where to find the link target.

Michael

> 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/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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: Eric Snow's implementation of PEP 421.

[Brett Cannon]

On Mon, Jun 4, 2012 at 11:10 AM, Barry Warsaw  wrote:

> Thanks for the second set of eyes, Brett.
>
> On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote:
>
> >> +.. data:: implementation
> >> +
> >> +   An object containing the information about the implementation of the
> >> +   currently running Python interpreter.  Its attributes are the those
> >>
> >
> >"the those" -> "those"
>
> I actually rewrote this section a bit:
>
>   An object containing information about the implementation of the
>   currently running Python interpreter.  The following attributes are
>   required to exist in all Python implementations.
>
> >> +   that all Python implementations must implement.
> >
> >Should you mention that VMs are allowed to add their own attributes that
> >are not listed?
>
> Here's how I rewrote it:
>
>   :data:`sys.implementation` may contain additional attributes specific to
>   the Python implementation.  These non-standard attributes must start with
>   an underscore, and are not described here.  Regardless of its contents,
>   :data:`sys.implementation` will not change during a run of the
> interpreter,
>   nor between implementation versions.  (It may change between Python
>   language versions, however.)  See `PEP 421` for more information.
>
> >>  They are described
> >> +   below.
> >> +
> >> +   *name* is the implementation's identifier, like ``'cpython'``.
> >
> >Is this guaranteed to be lowercase, or does it simply happen to be
> >lowercase in this instance?
>
> Yes, PEP 421 guarantees them to be lower cased.


>   *name* is the implementation's identifier, e.g. ``'cpython'``.  The
> actual
>   string is defined by the Python implementation, but it is guaranteed to
> be
>   lower case.
>
>
OK, then I would add a test to make sure this happens, like
``self.assertEqual(sys.implementation.name, sys.implement.name.lower())``
if you don't want to bother documenting it to make sure other VMs conform.

-Brett

>I think you meant to say ``sys.version_info(2, 7, 2, 'final', 0)``.
>
> Fixed.
>
> >> +   However, for a structured record type use
> >> :func:`~collections.namedtuple`
> >>
> >
> >What's with the ~?
>
> I'm not sure, but it seems to result in a cross-reference, and I see tildes
> used elsewhere, so I guess it's some reST/docutils magic.  I left this one
> in
> there.
>
> 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] Issue 2736: datetimes and Unix timestamps

[Barry Warsaw]

On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote:

>I recently opened issue14908. At work, I have to do a bunch of things
>with dates, times and timezones, and sometimes Unix timestamps are
>also involved (largely for easy compatibility with legacy APIs). I
>find the relative obscurity when converting datetimes to timestamps
>rather painful; IMO it should be possible to do everything I need
>straight from the datetime module objects, instead of having to
>involve the time or calendar modules.

I completely agree.  I've long considered this a wart in the stdlib, but never
got off my butt to do anything about it.  Thanks for filing this Dirkjan.

JFDI-ly y'rs,
-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] Issue 2736: datetimes and Unix timestamps

[Barry Warsaw]

On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:

>Personally, I would really like not having to think about the time
>module at all, except if I wanted to go low-level (e.g. get a Unix
>timestamp from scratch).

+1

Oh and, practicality beats purity.

-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] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

[Barry Warsaw]

On Jun 04, 2012, at 11:39 AM, Brett Cannon wrote:

>OK, then I would add a test to make sure this happens, like
>``self.assertEqual(sys.implementation.name, sys.implement.name.lower())``
>if you don't want to bother documenting it to make sure other VMs conform.

Good idea.  Done.

-Barry


signature.asc
Description: PGP 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] Issue 2736: datetimes and Unix timestamps

[Guido van Rossum]

On Mon, Jun 4, 2012 at 8:51 AM, Barry Warsaw  wrote:
> On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote:
>
>>Personally, I would really like not having to think about the time
>>module at all, except if I wanted to go low-level (e.g. get a Unix
>>timestamp from scratch).
>
> +1
>
> Oh and, practicality beats purity.

:-)

A big +1 on making conversions between POSIX timestamps and datetime
(with or without timezone) easier.

FWIW, I see a lot of people around me struggling with datetime objects
who would be better off using POSIX timestamps. E.g. lat week I heard
a colleague complain that he'd lost several hours trying to figure out
how to determine whether two datetimes were within 24h of each other,
getting confused by what was happening when the two were on different
sides of a DST transition (or worse, in the middle of one). This falls
under Nick's header "relative time", but the problem was that he was
trying to add this functionality to a framework that was storing
datetimes in a database, and they were previously used to record when
something had happened. He ended up having two versions of some code
-- one using timestamps, one using datetimes. Clearly that's
suboptimal.

-- 
--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] Daily reference leaks (d9b7399d9e45): sum=462

[Antoine Pitrou]

Le 03/06/2012 06:01, Benjamin Peterson a écrit :

2012/6/2:

results for d9b7399d9e45 on branch "default"


test_smtplib leaked [154, 154, 154] references, sum=462


Can other people reproduce this one? I can't.


$ ./python -m test -R 3:3 -uall test_smtpd test_smtplib
[1/2] test_smtpd
beginning 6 repetitions
123456
..
[2/2] test_smtplib
beginning 6 repetitions
123456
..
test_smtplib leaked [154, 154, 154] references, sum=462


___
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

[Christian Tismer]

On 6/4/12 4:11 PM, Carl Meyer wrote:

Hello Christian,

On 06/03/2012 03:56 PM, Éric Araujo wrote:

Le 02/06/2012 12:59, Christian Tismer a écrit :

One urgent question: will this feature be backported to Python 2.7?

Features are never backported to the stable versions.  virtualenv still
exists as a standalone project which is compatible with 2.7 though.

To add to Éric's answer: the key difference between virtualenv and
pyvenv, allowing pyvenv environments to be much simpler, relies on a
change to the interpreter itself. This won't be backported to 2.7, and
can't be released as a standalone package.

It would be possible to backport the Python API and command-line UI of
pyvenv (which are different from virtualenv) as a PyPI package
compatible with Python 2.7. Because it wouldn't have the interpreter
change, it would have to still create environments that look like
virtualenv environments (i.e. they'd have to have chunks of the stdlib
symlinked in and a custom site.py). I suppose this could be useful if
wanting to script creation of venvs across Python 2 and Python 3, but
the utility seems limited enough that I have no plans to do this.



Thank you call. Sad, but I see.

I guess I could produce an extension as add-on that mutates python2.7's
behavior ;-)

kidding-ly y'rs  - 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] Issue 2736: datetimes and Unix timestamps

[Alexander Belopolsky]

On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum  wrote:
> A big +1 on making conversions between POSIX timestamps and datetime
> (with or without timezone) easier.

I am all for achieving this goal, but I think the root of the problem
is not the lack of mxDT's ticks() method.  Note that someone who
requires robust behavior across the DST change would still be puzzled
about what to supply as arguments to the .ticks(offset=0.0,dst=-1)
method.

I think the key feature that is missing from datetime is the ability
to obtain local time complete with timezone offset.  See issue 9527.
Once we have that, adding  .ticks() that requires a timezone aware
datetime instance will complete the puzzle.

The problem with adding .ticks() to naive datetime instances is the
inherent ambiguity in what such instances represent. mxDT resolves
this by offering offset and dst arguments, but this is just moving the
problem from one place to another without solving it.
___
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] Issue 2736: datetimes and Unix timestamps

[Guido van Rossum]

Agreed that having a robust tzinfo object representing "local time,
whatever it is" would be a good feature too. This shouldn't have to
depend on the Olson tz database; it should just consult the libc
localtime function.

--Guido

On Mon, Jun 4, 2012 at 11:30 AM, Alexander Belopolsky
 wrote:
> On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum  wrote:
>> A big +1 on making conversions between POSIX timestamps and datetime
>> (with or without timezone) easier.
>
> I am all for achieving this goal, but I think the root of the problem
> is not the lack of mxDT's ticks() method.  Note that someone who
> requires robust behavior across the DST change would still be puzzled
> about what to supply as arguments to the .ticks(offset=0.0,dst=-1)
> method.
>
> I think the key feature that is missing from datetime is the ability
> to obtain local time complete with timezone offset.  See issue 9527.
> Once we have that, adding  .ticks() that requires a timezone aware
> datetime instance will complete the puzzle.
>
> The problem with adding .ticks() to naive datetime instances is the
> inherent ambiguity in what such instances represent. mxDT resolves
> this by offering offset and dst arguments, but this is just moving the
> problem from one place to another without solving it.



-- 
--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] Issue 2736: datetimes and Unix timestamps

[Alexander Belopolsky]

On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum  wrote:
> ...  I heard
> a colleague complain that he'd lost several hours trying to figure out
> how to determine whether two datetimes were within 24h of each other,
> getting confused by what was happening when the two were on different
> sides of a DST transition (or worse, in the middle of one).

I don't think this is a problem that a general purpose module such as
datetime can resolve.  Assuming that all instances are timezone aware,
either of the following tests may be appropriate for a given
application:

1) dt1 - dt2 == timedelta(1)

2) dt1.date() - dt2.date() == timedelta(1) and dt1.time() == dt2.time()

If your application deals with physical processes - (1) may be
appropriate, but if it deals with human schedules - (2) may be
appropriate.

The only right solution is to lobby your government to abandon the DST.
___
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] Issue 2736: datetimes and Unix timestamps

[Guido van Rossum]

On Mon, Jun 4, 2012 at 11:46 AM, Alexander Belopolsky
 wrote:
> On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum  wrote:
>> ...  I heard
>> a colleague complain that he'd lost several hours trying to figure out
>> how to determine whether two datetimes were within 24h of each other,
>> getting confused by what was happening when the two were on different
>> sides of a DST transition (or worse, in the middle of one).
>
> I don't think this is a problem that a general purpose module such as
> datetime can resolve.  Assuming that all instances are timezone aware,
> either of the following tests may be appropriate for a given
> application:
>
> 1) dt1 - dt2 == timedelta(1)
>
> 2) dt1.date() - dt2.date() == timedelta(1) and dt1.time() == dt2.time()
>
> If your application deals with physical processes - (1) may be
> appropriate, but if it deals with human schedules - (2) may be
> appropriate.

You seem to have misread -- I don't want to check if they are exactly
24 hours apart. I want to check if they are at most 24 hours apart.
The timezone can be assumed to be the same on dt1 and dt2.

A variant of (1) was what was needed -- the user had just confused
themselves into thinking they needed to convert to UTC first, and done
a poor job of that. This is a common situation.

> The only right solution is to lobby your government to abandon the DST.

That's not helping.

-- 
--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] Issue 2736: datetimes and Unix timestamps

[Victor Stinner]

> Anyway, I was pointed to issue 2736, which seems to have got a lot of
> discouraged core contributors (Victor, Antoine, David and Ka-Ping, to
> name just a few) up against Alexander (the datetime maintainer,
> AFAIK). It seems like a fairly straightforward case of practicality
> over purity: Alexander argues that there are "easy" one-liners to do
> things like datetime.totimestamp(), but most other people seem to not
> find them so easy.

Does mktime(dt.timetuple()) handle correctly tzinfo? And how do you get a
UNIX timestamp in the UTC timezone? (dt.utctotimestamp())

I tried to implement datetime.totimestamp() but I lost my mind in timezone.
It took me weeks to understand that the French timezone lost two hour near
1940 because of the World War II (to uniformize French and German
timezones)... France has not least than 12 timezones (the country, not
Metropolitan France) :-)

There is also the question of daylight saving time... Handling time is too
complex for my brain :-)

So I'm +1 for a simple datetime.totimestamp() method. But I'm unable to
write or review it.

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] Daily reference leaks (d9b7399d9e45): sum=462

[R. David Murray]

On Mon, 04 Jun 2012 19:36:52 +0200, Antoine Pitrou  wrote:
> Le 03/06/2012 06:01, Benjamin Peterson a écrit :
> > 2012/6/2:
> >> results for d9b7399d9e45 on branch "default"
> >> 
> >>
> >> test_smtplib leaked [154, 154, 154] references, sum=462
> >
> > Can other people reproduce this one? I can't.
> 
> $ ./python -m test -R 3:3 -uall test_smtpd test_smtplib
> [1/2] test_smtpd
> beginning 6 repetitions
> 123456
> ..
> [2/2] test_smtplib
> beginning 6 repetitions
> 123456
> ..
> test_smtplib leaked [154, 154, 154] references, sum=462

Gah.  Looks like a copy and paste error by one of the many people
(including me) who contributed to the last smtpd patch.  Should be fixed
by 079c1942eedf.

--David
___
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] Issue 2736: datetimes and Unix timestamps

[Alexander Belopolsky]

On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum  wrote:
> You seem to have misread -- I don't want to check if they are exactly
> 24 hours apart. I want to check if they are at most 24 hours apart.
> The timezone can be assumed to be the same on dt1 and dt2.
>
> A variant of (1) was what was needed -- the user had just confused
> themselves into thinking they needed to convert to UTC first, and done
> a poor job of that. This is a common situation.

It looks like if we had datetime.ticks() method, the user would simply
use it improperly and never ask his or her question.  Hardly the
result that we want.
___
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] Issue 2736: datetimes and Unix timestamps

[Guido van Rossum]

On Mon, Jun 4, 2012 at 1:57 PM, Alexander Belopolsky
 wrote:
> On Mon, Jun 4, 2012 at 3:05 PM, Guido van Rossum  wrote:
>> You seem to have misread -- I don't want to check if they are exactly
>> 24 hours apart. I want to check if they are at most 24 hours apart.
>> The timezone can be assumed to be the same on dt1 and dt2.
>>
>> A variant of (1) was what was needed -- the user had just confused
>> themselves into thinking they needed to convert to UTC first, and done
>> a poor job of that. This is a common situation.
>
> It looks like if we had datetime.ticks() method, the user would simply
> use it improperly and never ask his or her question.  Hardly the
> result that we want.

That's not my assessment of the situation.

But I don't know what ticks() is supposed to do. I am assuming we
would create totimestamp() and utctotimestamp() that mirror
fromtimestamp() and utcfromtimestamp(). Since we trust the user with
the latter we should trust them with the former.

-- 
--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] Language reference updated for metaclasses

[Nick Coghlan]

It's actually the pre-decoration class, since the cell is initialised
before the class is passed to the first decorator. I agree it's a little
weird, but I did try to describe it accurately in the new docs.

--
Sent from my phone, thus the relative brevity :)
On Jun 5, 2012 7:52 AM, "PJ Eby"  wrote:

> On Sun, May 20, 2012 at 4:38 AM, Nick Coghlan  wrote:
>
>> When writing the docs for types.new_class(), I discovered that the
>> description of the class creation process in the language reference
>> was not only hard to follow, it was actually *incorrect* when it came
>> to describing the algorithm for determining the correct metaclass.
>>
>> I rewrote the offending section of the language reference to both
>> describe the correct algorithm, and hopefully also to be easier to
>> read. Once people have had a chance to review the changes in the 3.3
>> docs, I'll backport the update to 3.2.
>>
>> Previous docs:
>> http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation
>> Updated docs:
>> http://docs.python.org/dev/reference/datamodel.html#customizing-class-creation
>>
>
> This is only sort-of-related, but while reviewing the above, the bit about
> __class__ caught my eye and brought this question to mind: how do class
> decorators interact with __class__?  Specifically, what happens (or more to
> the point, is *supposed* to happen and documented as such) if a class
> decorator returns a different class object?
>
> PEP 3135 doesn't address this, AFAICT.  It refers only to "the class", but
> doesn't say whether this is the class-as-returned-by-decorator or original
> defined class.  (ISTM that it should be the decorated class, since
> otherwise this would be different behavior compared to code that explicitly
> named the class.)
>
> (Oh, and the rewrite looked good!)
>
>
>
___
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] Language reference updated for metaclasses

[PJ Eby]

On Sun, May 20, 2012 at 4:38 AM, Nick Coghlan  wrote:

> When writing the docs for types.new_class(), I discovered that the
> description of the class creation process in the language reference
> was not only hard to follow, it was actually *incorrect* when it came
> to describing the algorithm for determining the correct metaclass.
>
> I rewrote the offending section of the language reference to both
> describe the correct algorithm, and hopefully also to be easier to
> read. Once people have had a chance to review the changes in the 3.3
> docs, I'll backport the update to 3.2.
>
> Previous docs:
> http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation
> Updated docs:
> http://docs.python.org/dev/reference/datamodel.html#customizing-class-creation
>

This is only sort-of-related, but while reviewing the above, the bit about
__class__ caught my eye and brought this question to mind: how do class
decorators interact with __class__?  Specifically, what happens (or more to
the point, is *supposed* to happen and documented as such) if a class
decorator returns a different class object?

PEP 3135 doesn't address this, AFAICT.  It refers only to "the class", but
doesn't say whether this is the class-as-returned-by-decorator or original
defined class.  (ISTM that it should be the decorated class, since
otherwise this would be different behavior compared to code that explicitly
named the class.)

(Oh, and the rewrite looked good!)
___
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] Language reference updated for metaclasses

[PJ Eby]

On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan  wrote:

> It's actually the pre-decoration class, since the cell is initialised
> before the class is passed to the first decorator. I agree it's a little
> weird, but I did try to describe it accurately in the new docs.
>
I see that now; it might be helpful to explicitly call that out.

This is adding to my list of Python 3 metaclass gripes, though.  In Python
2, I have in-the-body-of-a-class decorators implemented using metaclasses,
that will no longer work because of PEP 3115...  and if I switch to using
class decorators instead, then they won't work because of PEP 3135.  :-(

Meanwhile, mixing metaclasses is more difficult than ever, due to
__prepare__, and none of these flaws can be worked around officially,
because __build_class__ is an "implementation detail".  I *really* want to
like Python 3, but am still hoping against hope for the restoration of
hooks that __metaclass__ allowed, or some alternative mechanism that would
serve the same use cases.

Specifically, my main use case is method-level decorators and attribute
descriptors that need to interact with a user-defined class, *without*
requiring that user-defined class to either 1) redundantly decorate the
class or 2) inherit from some specific base or inject a specific
metaclass.  I only use __metaclass__ in 2.x for this because it's the only
way for code executed in a class body to gain access to the class at
creation time.

The reason for wanting this to be transparent is that 1) if you forget the
redundant class-decorator, mixin, or metaclass, stuff will silently not
work, and 2) mixing bases or metaclasses has much higher coupling to the
library providing the decorators or descriptors, and greatly increases the
likelihood of mixing metaclasses.

And at the moment, the only workaround I can come up with that *doesn't*
involve replacing __build_class__ is abusing the system trace hook; ISTM
that replacing __build_class__ is the better of those two options.

At this point, with the additions of types.new_class(), ISTM that every
Python implementation will have to *have* a __build_class__ function or its
equivalent; all that remains is the question of whether they allow
*replacing* it.
___
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[Nick Coghlan]

On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby  wrote:
> On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan  wrote:
>>
>> It's actually the pre-decoration class, since the cell is initialised
>> before the class is passed to the first decorator. I agree it's a little
>> weird, but I did try to describe it accurately in the new docs.
>
> I see that now; it might be helpful to explicitly call that out.
>
> This is adding to my list of Python 3 metaclass gripes, though.  In Python
> 2, I have in-the-body-of-a-class decorators implemented using metaclasses,
> that will no longer work because of PEP 3115...

I'm not quite following this one - do you mean they won't support
__prepare__, won't play nicely with other metaclasses that implement
__prepare__, or something else?

>  and if I switch to using
> class decorators instead, then they won't work because of PEP 3135.  :-(

Yeah, 3135 has had some "interesting" consequences :P (e.g. class body
level __class__ definitions are still broken at the moment if you also
reference super: http://bugs.python.org/issue12370)

> Meanwhile, mixing metaclasses is more difficult than ever, due to
> __prepare__, and none of these flaws can be worked around officially,
> because __build_class__ is an "implementation detail".  I *really* want to
> like Python 3, but am still hoping against hope for the restoration of hooks
> that __metaclass__ allowed, or some alternative mechanism that would serve
> the same use cases.
>
> Specifically, my main use case is method-level decorators and attribute
> descriptors that need to interact with a user-defined class, *without*
> requiring that user-defined class to either 1) redundantly decorate the
> class or 2) inherit from some specific base or inject a specific metaclass.
> I only use __metaclass__ in 2.x for this because it's the only way for code
> executed in a class body to gain access to the class at creation time.
>
> The reason for wanting this to be transparent is that 1) if you forget the
> redundant class-decorator, mixin, or metaclass, stuff will silently not
> work,

Why would it silently not work? What's preventing you from having
decorators that create wrapped functions that fail noisily when
called, then providing a class decorator that unwraps those functions,
fixes them up with the class references they need and stores the
unwrapped and updated versions back on the class.

You call it redundant, I call it explicit.

> and 2) mixing bases or metaclasses has much higher coupling to the
> library providing the decorators or descriptors, and greatly increases the
> likelihood of mixing metaclasses.

So don't do that, then. Be explicit.

> And at the moment, the only workaround I can come up with that *doesn't*
> involve replacing __build_class__ is abusing the system trace hook; ISTM
> that replacing __build_class__ is the better of those two options.

Stop trying to be implicit. Implicit magic sucks, don't add more (PEP
3135 is bad enough).

> At this point, with the additions of types.new_class(), ISTM that every
> Python implementation will have to *have* a __build_class__ function or its
> equivalent; all that remains is the question of whether they allow
> *replacing* it.

types.new_class() is actually a pure Python reimplementation of the
PEP 3115 algorithm. Why would it imply the need for a __build_class__
function?

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

[Python-Dev] issues with installing and importing rdflib and rdfextras in python and eclipse pydev

[ayodele akingbulu]

Hi,

I have issues with the installation of rdflib and rdfextras packages on
windows for python 3.2.3. I cannot find anywhere in the document detailing
how to install this packages and succesfully import them in a python
program. not to talk less of accessing it on eclipse indigo.

Kindly help to look into this issue as it might be a bug.

Regards,
Ayo
___
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[Ethan Furman]

Nick Coghlan wrote:

On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby wrote:

The reason for wanting this to be transparent is that 1) if you forget the
redundant class-decorator, mixin, or metaclass, stuff will silently not
work,


Why would it silently not work? What's preventing you from having
decorators that create wrapped functions that fail noisily when
called, then providing a class decorator that unwraps those functions,
fixes them up with the class references they need and stores the
unwrapped and updated versions back on the class.

You call it redundant, I call it explicit.



The first time you specify something, it's explicit; if you have to 
specify the same thing a second time, it's redundant;  if this was a 
good thing why do we say DRY so often?


~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] what is happening with the regex module going into Python 3.3?

[MRAB]

(I've been having trouble with my email recently, so I missed this
thread amongst others.)

I personally am no longer that bothered about whether the regex module
makes it into stdlib, but I am still be maintaining it on PyPI. If
someone else wants to integrate it I would, of course, be willing to
help out.

As long as they basically have the same source code, any bugs or other
problems in the integrated module would be shared by the separate
module, and I would want to fix them, so any fix in the separate module
could be replicated easily in the integrated module.

It already works with Python 3.3 alpha, including PEP 393, BTW.
___
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 #11022: locale.getpreferredencoding() must not set temporary LC_CTYPE

[Victor Stinner]

Hi,

I would like to know if it is too late (or not) to change the
behaviour of open() for text files (TextIOWrapper). Currently, it
calls locale.getpreferredencoding() to get the locale encoding by
default. It is convinient and I like this behaviour... except that it
changes temporary the LC_CTYPE locale to get the user prefered
encoding instead of using the current encoding. Python 3 does already
uses the user preferred encoding as the current encoding at startup.
Changing temporary the current encoding to the user preferred encoding
is useless and dangerous (may cause issues in multithreaded
applications). Setting the current locale using locale.setlocale()
does not affect TextIOWrapper, it's also surprising.

The change is just to replace locale.getpreferredencoding() by
locale.getpreferredencoding(False) in the io module.

Can I change this behaviour (before the first beta) in Python 3.3?

See the issue #11022 (and maybe also #6203) for the discussion on this change.

--

Leaving LC_CTYPE unchanged (use the "C" locale, which is ASCII in most
cases) at Python startup would be a major change in Python 3. I don't
want to do that. You would see a lot of mojibake in your GUIs and get
a lot of ugly surrogate characters in filenames because of the PEP
393.

Setting the LC_CTYPE to the user preferred encoding is just very
convinient and helps Python to speak to the user though the console,
to the filesystem, to pass arguments on a command line of a
subprocess, etc. For example, you cannot pass non-ASCII characters to
a subprocess, characters written by the user in your GUI, if your
current LC_CTYPE locale is C (ASCII): you get an Unicode encode error.

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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[PJ Eby]

On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan  wrote:

> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby  wrote:
> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan  wrote:
> >>
> >> It's actually the pre-decoration class, since the cell is initialised
> >> before the class is passed to the first decorator. I agree it's a little
> >> weird, but I did try to describe it accurately in the new docs.
> >
> > I see that now; it might be helpful to explicitly call that out.
> >
> > This is adding to my list of Python 3 metaclass gripes, though.  In
> Python
> > 2, I have in-the-body-of-a-class decorators implemented using
> metaclasses,
> > that will no longer work because of PEP 3115...
>
> I'm not quite following this one - do you mean they won't support
> __prepare__, won't play nicely with other metaclasses that implement
> __prepare__, or something else?
>

I mean that class-level __metaclass__ is no longer supported as of PEP
3115, so I can't use that as a way to non-invasively obtain the enclosing
class at class creation time.

(Unfortunately, I didn't realize until relatively recently that it wasn't
supported any more; the PEP itself doesn't say the functionality will be
removed.  Otherwise, I'd have lobbied sooner for a better migration path.)



> > Meanwhile, mixing metaclasses is more difficult than ever, due to
> > __prepare__, and none of these flaws can be worked around officially,
> > because __build_class__ is an "implementation detail".  I *really* want
> to
> > like Python 3, but am still hoping against hope for the restoration of
> hooks
> > that __metaclass__ allowed, or some alternative mechanism that would
> serve
> > the same use cases.
> >
> > Specifically, my main use case is method-level decorators and attribute
> > descriptors that need to interact with a user-defined class, *without*
> > requiring that user-defined class to either 1) redundantly decorate the
> > class or 2) inherit from some specific base or inject a specific
> metaclass.
> > I only use __metaclass__ in 2.x for this because it's the only way for
> code
> > executed in a class body to gain access to the class at creation time.
> >
> > The reason for wanting this to be transparent is that 1) if you forget
> the
> > redundant class-decorator, mixin, or metaclass, stuff will silently not
> > work,
>
> Why would it silently not work? What's preventing you from having
> decorators that create wrapped functions that fail noisily when
> called, then providing a class decorator that unwraps those functions,
> fixes them up with the class references they need and stores the
> unwrapped and updated versions back on the class.
>

If you are registering functions or attributes in some type of registry
either at the class level or in some sort of global registry, then the
function will never be called or the attribute accessed, so there is no
opportunity to give an error message saying, "you should have done this".
Something will simply fail to happen that should have happened.

Essentially, the lack of this hook forces things to be done outside of
class bodies that make more sense to be done *inside* class bodies.


> and 2) mixing bases or metaclasses has much higher coupling to the
> > library providing the decorators or descriptors, and greatly increases
> the
> > likelihood of mixing metaclasses.
>
> So don't do that, then. Be explicit.
>

Easy for you to say.  However, I have *many* decorators and descriptors
which follow this pattern, in various separately-distributed libraries.  If
*each* of these libraries now grows a redundant class decorator for Python
3, then any code which uses more than one in the same class will now have a
big stack of decorator noise on top of it...  and missing any one of them
will cause silent failure.

And of course, all other libraries which use these decorators and
descriptors will *also* have to add this line-noise in order to port to
Python 3...  including the applications that depend on those libraries.
And let's not forget the people who subclass or extend any of my decorators
or descriptors -- they will need to tell *their* users to begin adding
redundant class-level decorators, and so on.



> > And at the moment, the only workaround I can come up with that *doesn't*
> > involve replacing __build_class__ is abusing the system trace hook; ISTM
> > that replacing __build_class__ is the better of those two options.
>
> Stop trying to be implicit. Implicit magic sucks,


The fact that a method-level decorator or descriptor might need access to
its containing class when the class is created does not in any way make it
*intrinsically* "magical" or "implicit".  The focus here is on the
decorator or descriptor: the class access is just an implementation detail,
and generally doesn't involve modifying the class itself.

So, please let's not start FUDding here.  None of the descriptors or
decorators I'm describing are implicit or magical in the least.  They are
documented as doing what they do, and they use pe

Re: [Python-Dev] what is happening with the regex module going into Python 3.3?

[Steven D'Aprano]

MRAB wrote:


I personally am no longer that bothered about whether the regex module
makes it into stdlib, but I am still be maintaining it on PyPI. If
someone else wants to integrate it I would, of course, be willing to
help out.


Are you withdrawing your offer to maintain regex in the stdlib?



As long as they basically have the same source code, any bugs or other
problems in the integrated module would be shared by the separate
module, and I would want to fix them, so any fix in the separate module
could be replicated easily in the integrated module.


But changes to the stdlib (bug fixes or functional changes) are very likely to 
run at a slower pace to what third-party packages can afford. If you continue 
to develop regex outside of the stdlib, that could cause complications.



--
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] what is happening with the regex module going into Python 3.3?

[Brian Curtin]

On Mon, Jun 4, 2012 at 7:31 PM, Steven D'Aprano  wrote:
> But changes to the stdlib (bug fixes or functional changes) are very likely
> to run at a slower pace to what third-party packages can afford. If you
> continue to develop regex outside of the stdlib, that could cause
> complications.

Developing outside of the standard library isn't an option. You could
always backport things to the external version like the unittest2
project, but standard library modules need to be grown and fixed first
in the standard library.
___
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] Issue 2736: datetimes and Unix timestamps

[Alexander Belopolsky]

On Mon, Jun 4, 2012 at 5:25 PM, Guido van Rossum  wrote:
..
> But I don't know what ticks() is supposed to do.

"""
.ticks(offset=0.0,dst=-1)

Returns a float representing the instances value in ticks (see above).

The conversion routine assumes that the stored date/time value is
given in local time.

The given value for dst is used by the conversion (0 = DST off, 1 =
DST on, -1 = unkown) and offset is subtracted from the resulting
value.

The method raises a RangeErrorexception if the objects value does not
fit into the system's ticks range.

Note:On some platforms the C lib's mktime() function that this method
uses does not allow setting DST to an arbitrary value. The module
checks for this and raises a SystemError in case setting DST to 0 or 1
does not result in valid results.
""" mxDateTime Documentation,



> I am assuming we
> would create totimestamp() and utctotimestamp() that mirror
> fromtimestamp() and utcfromtimestamp().

First, with the introduction of timezone.utc, the use of utc...
methods should be discouraged.

fromtimestamp(s,timezeone.utc) is better than utcfromtimestamp();
now(timezeone.utc)  is better than utcnow(); and
dt.astimezone(timezone.utc).timetuple() is better than dt.utctimetuple()

The advantage of the first two is that they produce aware datetime
instances.  The last example may appear more verbose, but in most
applications, dt.astimezone(timezone.utc) is really what is needed.

> Since we trust the user with
> the latter we should trust them with the former.
>

This does not follow.  When you deal with non-monotonic functions,
defining the inverse functions requires considerably more care than
defining the original.  For example, defining sqrt(), requires
choosing the positive root.  For arcsin(), you need to choose between
infinitely many branches.   I don't think many users would appreciate
a math library where sqrt() and arcsin() take an optional branch=
argument, but mxDT's ticks() features this very design with its dst=
flag.  Most users will ignore optional dst= and live with the
resulting bugs.  We had several such bugs in stdlib and they went
unnoticed for years.
___
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] what is happening with the regex module going into Python 3.3?

[MRAB]

On 05/06/2012 01:31, Steven D'Aprano wrote:

MRAB wrote:


 I personally am no longer that bothered about whether the regex module
 makes it into stdlib, but I am still be maintaining it on PyPI. If
 someone else wants to integrate it I would, of course, be willing to
 help out.


Are you withdrawing your offer to maintain regex in the stdlib?



 As long as they basically have the same source code, any bugs or other
 problems in the integrated module would be shared by the separate
 module, and I would want to fix them, so any fix in the separate module
 could be replicated easily in the integrated module.


But changes to the stdlib (bug fixes or functional changes) are very likely to
run at a slower pace to what third-party packages can afford. If you continue
to develop regex outside of the stdlib, that could cause complications.


I'm not planning any further changes to regex. I think it already has
enough features...

That just leaves 1) bug fixes, which you'd also want fixed in the
stdlib, and 2) functional changes requested for the stdlib, which you'd
presumably also want in the third-party package for those using earlier
versions of Python.
___
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] issues with installing and importing rdflib and rdfextras in python and eclipse pydev

[Terry Reedy]

On 6/4/2012 7:27 PM, ayodele akingbulu wrote:


I have issues with the installation of rdflib and rdfextras packages on
windows for python 3.2.3. I cannot find anywhere in the document
detailing how to install this packages and succesfully import them in a
python program. not to talk less of accessing it on eclipse indigo.


pydev list is for the development of future Python and cpython, not for 
usage questions about current python and definitely not for questions 
about 3rd party programs.


http://pypi.python.org/pypi/rdflib  says

"Support is available through the rdflib-dev group:
http://groups.google.com/group/rdflib-dev
"
Inquire there.


Kindly help to look into this issue as it might be a bug.


We have no responsibility for bugs in rdflib and its docs.

--
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[Nick Coghlan]

On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby  wrote:
> On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan  wrote:
>>
>> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby  wrote:
>> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan  wrote:
>> >>
>> >> It's actually the pre-decoration class, since the cell is initialised
>> >> before the class is passed to the first decorator. I agree it's a
>> >> little
>> >> weird, but I did try to describe it accurately in the new docs.
>> >
>> > I see that now; it might be helpful to explicitly call that out.
>> >
>> > This is adding to my list of Python 3 metaclass gripes, though.  In
>> > Python
>> > 2, I have in-the-body-of-a-class decorators implemented using
>> > metaclasses,
>> > that will no longer work because of PEP 3115...
>>
>> I'm not quite following this one - do you mean they won't support
>> __prepare__, won't play nicely with other metaclasses that implement
>> __prepare__, or something else?
>
>
> I mean that class-level __metaclass__ is no longer supported as of PEP 3115,
> so I can't use that as a way to non-invasively obtain the enclosing class at
> class creation time.
>
> (Unfortunately, I didn't realize until relatively recently that it wasn't
> supported any more; the PEP itself doesn't say the functionality will be
> removed.  Otherwise, I'd have lobbied sooner for a better migration path.)

As in the "def __metaclass__(name, bases, ns): return type(name,
bases, ns)" functionality?

You can still pass an ordinary callable as the metaclass parameter and
it will behave the same as the old class level __metaclass__
definition.

I personally wouldn't be averse to bringing back the old spelling for
the case where __prepare__ isn't needed - you're right that it's a
convenient way to do a custom callable that gets inherited by
subclasses.

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] what is happening with the regex module going into Python 3.3?

[Terry Reedy]

On 6/4/2012 9:22 PM, MRAB wrote:


I'm not planning any further changes to regex. I think it already has
enough features...


Do you have any idea where regex + Python stands in regard to Unicode 
TR18 support levels? http://unicode.org/reports/tr18/
While most of the Tailored Support Level 3 strikes me as out of scope 
for the stdlib, I can imagine getting requests for any other stuff not 
already included.


--
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[Eric Snow]

On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby  wrote:
> I mean that class-level __metaclass__ is no longer supported as of PEP 3115,
> so I can't use that as a way to non-invasively obtain the enclosing class at
> class creation time.

Depends on what you mean by non-invasive:

* http://code.activestate.com/recipes/577813/
* http://code.activestate.com/recipes/577867/

-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] Language reference updated for metaclasses

[Eli Bendersky]

On Sun, May 20, 2012 at 10:38 AM, Nick Coghlan  wrote:
> When writing the docs for types.new_class(), I discovered that the
> description of the class creation process in the language reference
> was not only hard to follow, it was actually *incorrect* when it came
> to describing the algorithm for determining the correct metaclass.
>
> I rewrote the offending section of the language reference to both
> describe the correct algorithm, and hopefully also to be easier to
> read. Once people have had a chance to review the changes in the 3.3
> docs, I'll backport the update to 3.2.
>
> Previous docs: 
> http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation
> Updated docs: 
> http://docs.python.org/dev/reference/datamodel.html#customizing-class-creation
>

"if an explicit metaclass is given and it is not an instance of
type(), then it is used directly as the metaclass"

Could you elaborate on this point? Would it perhaps be clearer to say
"if an explicit metaclass is given and it is not a class"?

Eli
___
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[PJ Eby]

On Mon, Jun 4, 2012 at 10:25 PM, Nick Coghlan  wrote:

> On Tue, Jun 5, 2012 at 10:10 AM, PJ Eby  wrote:
> > On Mon, Jun 4, 2012 at 7:18 PM, Nick Coghlan  wrote:
> >>
> >> On Tue, Jun 5, 2012 at 8:58 AM, PJ Eby  wrote:
> >> > On Mon, Jun 4, 2012 at 6:15 PM, Nick Coghlan 
> wrote:
> >> >>
> >> >> It's actually the pre-decoration class, since the cell is initialised
> >> >> before the class is passed to the first decorator. I agree it's a
> >> >> little
> >> >> weird, but I did try to describe it accurately in the new docs.
> >> >
> >> > I see that now; it might be helpful to explicitly call that out.
> >> >
> >> > This is adding to my list of Python 3 metaclass gripes, though.  In
> >> > Python
> >> > 2, I have in-the-body-of-a-class decorators implemented using
> >> > metaclasses,
> >> > that will no longer work because of PEP 3115...
> >>
> >> I'm not quite following this one - do you mean they won't support
> >> __prepare__, won't play nicely with other metaclasses that implement
> >> __prepare__, or something else?
> >
> >
> > I mean that class-level __metaclass__ is no longer supported as of PEP
> 3115,
> > so I can't use that as a way to non-invasively obtain the enclosing
> class at
> > class creation time.
> >
> > (Unfortunately, I didn't realize until relatively recently that it wasn't
> > supported any more; the PEP itself doesn't say the functionality will be
> > removed.  Otherwise, I'd have lobbied sooner for a better migration
> path.)
>
> As in the "def __metaclass__(name, bases, ns): return type(name,
> bases, ns)" functionality?
>

The part where you can do that *dynamically in the class body* from a
decorator or other code, yes.

You can still pass an ordinary callable as the metaclass parameter and
> it will behave the same as the old class level __metaclass__
> definition.
>

Which runs afoul of the requirement that users of the in-body decorator or
descriptor not have to 1) make the extra declaration and 2) deal with the
problem of needing multiple metaclasses.  (Every framework that wants to do
this sort of thing will end up having to have its own metaclass, and you
won't be able to use them together without first creating a mixed
metaclass.)



> I personally wouldn't be averse to bringing back the old spelling for
> the case where __prepare__ isn't needed - you're right that it's a
> convenient way to do a custom callable that gets inherited by
> subclasses.
>

That was a nice hack, but not one I'd lose any sleep over; the translation
to PEP 3115 syntax is straightforward even if less elegant.  It's the
*dynamic* character that's missing in 3.x.  In any case, I don't use the
__metaclass__ hook to actually *change* the metaclass at all; it's simply
the easiest way to get at the class as soon as its built in 2.x.

If there were a way to register a function to be called as soon as an
enclosing class is created, I would use that instead.
___
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] Possible rough edges in Python 3 metaclasses (was Re: Language reference updated for metaclasses)

[PJ Eby]

On Mon, Jun 4, 2012 at 10:43 PM, Eric Snow wrote:

> On Mon, Jun 4, 2012 at 6:10 PM, PJ Eby  wrote:
> > I mean that class-level __metaclass__ is no longer supported as of PEP
> 3115,
> > so I can't use that as a way to non-invasively obtain the enclosing
> class at
> > class creation time.
>
> Depends on what you mean by non-invasive:
>

Non-invasive meaning, "not requiring the user of the descriptor or
decorator to make extra declarations-at-a-distance, especially ones that
increase the likelihood of clashing machinery if multiple frameworks
require the same functionality."  ;-)

That means class decorators, mixins, and explicit metaclasses don't work.
The class decorator adds yak shaving, and the others lead to functional
clashing.

Currently, my choices for porting these libraries (and their dependents) to
Python 3 are (in roughly descending order of preference):

1. Replace __builtins__.__build_class__ and hope PyPy et al follow
CPython's lead,

2. Abuse sys.set_trace() and __class__ to get a callback at the right
moment (because set_trace() *is* supported on other implementations in
practice right now, at least for 2.x), or

3. Write a class decorator like "@py3_is_less_dynamic_than_py2", put it in
a common library, and ask everybody and their dog to use it on any class
whose body contains any decorator or descriptor from any of my libraries
(or which someone else *derived* from any of my libraries, etc. ad
nauseam), oh and good luck finding which ones all of them are, and yeah, if
you miss it, stuff might not work.  (Note, by the way, that this goes
against the advice of not changing APIs while migrating to Python 3...  and
let's not forget all the documentation that has to be changed, each piece
of which must explain and motivate this new and apparently-pointless
decorator to the library's user.)

I would prefer to have an option 4 or 5 (where there's a standard Python
way to get a class creation callback from a class body), but #1 is honestly
the most attractive at the moment, as I might only need to implement it in
*one* library, with no changes to clients, including people who've built
stuff based on that library or any of its clients, recursively.  (#2 would
also do it, but I was *really* hoping to get rid of that hack in Python 3.)

Given these choices, I hope it's more understandable why I'd want to lobby
for at least documenting __build_class__ and its replaceability, and
perhaps encouraging other Python 3 implementations to offer the same
feature.  Given that implementing PEP 3115 and types.new_class() mean the
same functionality has to be present, and given that class creation is
generally not a performance-critical function, there's little reason for a
sufficiently dynamic Python implementation (by which I basically mean
Jython, IronPython, and PyPy) to support it.  (More-static implementations
don't always even support metaclasses to begin with, so they're not going
to lose anything important by not supporting dynamic __build_class__.)
___
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] Issue #11022: locale.getpreferredencoding() must not set temporary LC_CTYPE

[Martin v. Löwis]

Can I change this behaviour (before the first beta) in Python 3.3?


Fine with me. That code predates 43e32b2b4004. I don't recall
discussion to set the LC_CTYPE locale and not take it back, but
apparently, this is what Python currently does, which means that
another setlocale call is not necessary.

So in theory, your change should have no effect, unless somebody has 
modified some environment variables.


Regards,
Martin

___
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: Fix potential NameError in multiprocessing.Condition.wait()

[Eli Bendersky]

Can you add a testcase for this?

On Mon, Jun 4, 2012 at 9:01 PM, richard.oudkerk
 wrote:
> http://hg.python.org/cpython/rev/3baeb5e13dd2
> changeset:   77348:3baeb5e13dd2
> user:        Richard Oudkerk 
> date:        Mon Jun 04 18:59:07 2012 +0100
> summary:
>  Fix potential NameError in multiprocessing.Condition.wait()
>
> files:
>  Lib/multiprocessing/synchronize.py |  3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
>
> diff --git a/Lib/multiprocessing/synchronize.py 
> b/Lib/multiprocessing/synchronize.py
> --- a/Lib/multiprocessing/synchronize.py
> +++ b/Lib/multiprocessing/synchronize.py
> @@ -216,7 +216,7 @@
>
>         try:
>             # wait for notification or timeout
> -            ret = self._wait_semaphore.acquire(True, timeout)
> +            return self._wait_semaphore.acquire(True, timeout)
>         finally:
>             # indicate that this thread has woken
>             self._woken_count.release()
> @@ -224,7 +224,6 @@
>             # reacquire lock
>             for i in range(count):
>                 self._lock.acquire()
> -            return ret
>
>     def notify(self):
>         assert self._lock._semlock._is_mine(), 'lock is not owned'
>
> --
> 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