Re: [Python-Dev] question about packaging

[Doug Hellmann]

Is that where the discussions are actively happening? Last time I looked at it 
I thought there was a google group or something. It's bee quite a while, 
though, so I may just be confused.

On Dec 28, 2012, at 6:12 PM, Antonio Cavallo wrote:

> There's the distutil mailing list:
> 
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 
> 
> Doug Hellmann wrote:
>> A couple of us from the OpenStack project are interested in getting involved 
>> in the packaging rewrite/update project. I was following that work for a 
>> while, but have lost track of its current state. Can someone point me to the 
>> right mailing list, and maybe a status page or something so I can start 
>> figuring out where we might be able to help?
>> 
>> Thanks,
>> Doug
>> 
>> ___
>> 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/a.cavallo%40cavallinux.eu

___
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 431 Time zone support improvements - Update

[Antoine Pitrou]

On Sat, 29 Dec 2012 16:00:39 +1000
Nick Coghlan  wrote:
> 
> > Discussion
> > ==
> >
> > Should the windows installer include the data package?
> > --
> >
> > It has been suggested that the Windows installer should include the data
> > package. This would mean that an explicit installation no longer would be
> > needed on Windows. On the other hand, that would mean that many using
> > Windows
> > would not be aware that the database quickly becomes outdated and would not
> > keep it updated.
> 
> I'm still a fan of *always* shipping fallback tzdata, regardless of
> platform. The stdlib would then look in three places for timezone data
> when datetime.timezone was first imported:
> 
> 1. the "tzdata-update" database
> 2. the OS provided database
> 3. the fallback database

+1 !

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] question about packaging

[Antoine Pitrou]

On Fri, 28 Dec 2012 17:59:05 -0500
Doug Hellmann  wrote:
> A couple of us from the OpenStack project are interested in getting involved 
> in the packaging rewrite/update project. I was following that work for a 
> while, but have lost track of its current state. Can someone point me to the 
> right mailing list, and maybe a status page or something so I can start 
> figuring out where we might be able to help?

The current effort seems to be distlib, Vinay's project to gather the
"good parts" of packaging and distutils as a library API:
http://packages.python.org/distlib/
(there's an active bitbucket repo)

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] PEP 431 Time zone support improvements - Update

[Dirkjan Ochtman]

On Sat, Dec 29, 2012 at 11:45 AM, Antoine Pitrou  wrote:
>> I'm still a fan of *always* shipping fallback tzdata, regardless of
>> platform. The stdlib would then look in three places for timezone data
>> when datetime.timezone was first imported:
>>
>> 1. the "tzdata-update" database
>> 2. the OS provided database
>> 3. the fallback database
>
> +1 !

Yeah, from me as well.

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] question about packaging

[Antonio Cavallo]

Correct if I'm wrong but distlib isn't targeting resources managent? 
distutils is targeted to distribute python modules/packages instead; 
small differences but on the field they really mean different things.


distlib is under http://hg.python.org/distlib too :O
..my first guess would be that's the released "branch".




Antoine Pitrou wrote:

On Fri, 28 Dec 2012 17:59:05 -0500
Doug Hellmann  wrote:

A couple of us from the OpenStack project are interested in getting involved in 
the packaging rewrite/update project. I was following that work for a while, 
but have lost track of its current state. Can someone point me to the right 
mailing list, and maybe a status page or something so I can start figuring out 
where we might be able to help?


The current effort seems to be distlib, Vinay's project to gather the
"good parts" of packaging and distutils as a library API:
http://packages.python.org/distlib/
(there's an active bitbucket repo)

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/a.cavallo%40cavallinux.eu

___
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] question about packaging

[Doug Hellmann]

On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote:

> On Fri, 28 Dec 2012 17:59:05 -0500
> Doug Hellmann  wrote:
>> A couple of us from the OpenStack project are interested in getting involved 
>> in the packaging rewrite/update project. I was following that work for a 
>> while, but have lost track of its current state. Can someone point me to the 
>> right mailing list, and maybe a status page or something so I can start 
>> figuring out where we might be able to help?
> 
> The current effort seems to be distlib, Vinay's project to gather the
> "good parts" of packaging and distutils as a library API:
> http://packages.python.org/distlib/
> (there's an active bitbucket repo)
> 
> Regards
> 
> Antoine.

Thanks, I'll start digging in there and reading the PEPs to catch up.

Doug

___
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 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 7:00 AM, Nick Coghlan  wrote:

> On Sat, Dec 29, 2012 at 6:23 AM, Lennart Regebro 
> wrote:
> > Happy Holidays! Here is the update of PEP 431 with the changes that
> emerged
> > after the earlier discussion.
> >
> > A raw download is here:
> > https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
>
> For UI purposes, "pytz" has some helpers to get lists of timezone
> names (all, common and country specific):
> http://pytz.sourceforge.net/#helpers
>

Funnily enough, I woke up this morning thinking that this should be added,
and wondering why pytz didn't have such lists. So I just missed (or rather
forgot) that they existed. I'll add them.

Is there a specific reason you chose to exclude those from the PEP?
>
> > Discussion
> > ==
> >
> > Should the windows installer include the data package?
> > --
> >
> > It has been suggested that the Windows installer should include the data
> > package. This would mean that an explicit installation no longer would be
> > needed on Windows. On the other hand, that would mean that many using
> > Windows
> > would not be aware that the database quickly becomes outdated and would
> not
> > keep it updated.
>
> I'm still a fan of *always* shipping fallback tzdata


Yes, and I did update the rest of the PEP with this, but I missed the
discussion part.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 431 Time zone support improvements - Update

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/29/2012 01:00 AM, Nick Coghlan wrote:

> I'm still a fan of *always* shipping fallback tzdata, regardless of 
> platform. The stdlib would then look in three places for timezone
> data when datetime.timezone was first imported:
> 
> 1. the "tzdata-update" database 2. the OS provided database 3. the
> fallback database

- -Lots for enabling fallback by default except on platforms known not to
have their own database, or given some explicit 'siteconfigure.py'-like
knob enabling it.  A clean error is better than a bad-but-silent answer.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDfOMEACgkQ+gerLs4ltQ7mfQCgxV13Ch7eW/yDwCPMfEebeNuY
xr0An1yvuUkVUQGY8nKDt9GxemdLlHMA
=JtY0
-END 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] PEP 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver  wrote:

> - -Lots for enabling fallback by default except on platforms known not to
> have their own database


Well, it's the same thing really. If the platform does have a database, the
fallback will not be used.
Of course, there is the case of the database existing on the platform
normally, but somebody for some reason deleting the files, but I don't
think that case deserves an error message.

I also expect that most platform distributions, such as for Ubuntu, will
not include the fallback database, as it will never be used. I'll add
something about that and that we need to raise an error of some sort (any
opinions on what?) if no database is found at all.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro  wrote:

> On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver wrote:
>
>> - -Lots for enabling fallback by default except on platforms known not to
>> have their own database
>
>
> Well, it's the same thing really. If the platform does have a database,
> the fallback will not be used.
> Of course, there is the case of the database existing on the platform
> normally, but somebody for some reason deleting the files, but I don't
> think that case deserves an error message.
>
> I also expect that most platform distributions, such as for Ubuntu, will
> not include the fallback database, as it will never be used. I'll add
> something about that and that we need to raise an error of some sort (any
> opinions on what?) if no database is found at all.
>

Actually I already added that, but opinions on what error to raise are
still welcome. Currently it says:

If no database is found an ``UnknownTimeZoneError`` or subclass thereof
will
be raised with a message explaining that no zoneinfo database can be
found,
but that you can install one with the ``tzdata-update`` package.
___
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 431 Time zone support improvements - Update

[Arfrever Frehtes Taifersar Arahesis]

2012-12-29 19:54:42 Lennart Regebro napisał(a):
> On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver  wrote:
> 
> > - -Lots for enabling fallback by default except on platforms known not to
> > have their own database
> 
> Well, it's the same thing really. If the platform does have a database, the
> fallback will not be used.

I suggest that configure script support --enable-internal-timezone-database / 
--disable-internal-timezone-database options.
--disable-internal-timezone-database should cause that installational targets 
in Makefile would not install files of timezone
database.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.
___
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 431 Time zone support improvements - Update

[Antoine Pitrou]

On Sat, 29 Dec 2012 19:56:43 +0100
Lennart Regebro  wrote:
> On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro  wrote:
> 
> > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver wrote:
> >
> >> - -Lots for enabling fallback by default except on platforms known not to
> >> have their own database
> >
> >
> > Well, it's the same thing really. If the platform does have a database,
> > the fallback will not be used.
> > Of course, there is the case of the database existing on the platform
> > normally, but somebody for some reason deleting the files, but I don't
> > think that case deserves an error message.
> >
> > I also expect that most platform distributions, such as for Ubuntu, will
> > not include the fallback database, as it will never be used. I'll add
> > something about that and that we need to raise an error of some sort (any
> > opinions on what?) if no database is found at all.
> >
> 
> Actually I already added that, but opinions on what error to raise are
> still welcome. Currently it says:
> 
> If no database is found an ``UnknownTimeZoneError`` or subclass thereof
> will
> be raised with a message explaining that no zoneinfo database can be
> found,
> but that you can install one with the ``tzdata-update`` package.

Why should we care about that situation if we *do* provide a database?
Distributions can decide to exclude some files from their packages, but
it's their problem, not ours.

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] [Python-checkins] cpython (3.3): Issue #16641: Fix default values of sched.scheduler.enter arguments were

[Eli Bendersky]

On Sat, Dec 29, 2012 at 11:17 AM, serhiy.storchaka <
python-check...@python.org> wrote:

> http://hg.python.org/cpython/rev/1c9c0f92df65
> changeset:   81134:1c9c0f92df65
> branch:  3.3
> parent:  81132:5db0833f135b
> user:Serhiy Storchaka 
> date:Sat Dec 29 21:13:45 2012 +0200
> summary:
>   Issue #16641: Fix default values of sched.scheduler.enter arguments were
> modifiable.
>
> files:
>   Doc/library/sched.rst |  23 ++-
>   Lib/sched.py  |   8 ++--
>   Misc/NEWS |   3 +++
>   3 files changed, 23 insertions(+), 11 deletions(-)
>
>
> diff --git a/Doc/library/sched.rst b/Doc/library/sched.rst
> --- a/Doc/library/sched.rst
> +++ b/Doc/library/sched.rst
> @@ -36,19 +36,22 @@
>
> >>> import sched, time
> >>> s = sched.scheduler(time.time, time.sleep)
> -   >>> def print_time(): print("From print_time", time.time())
> +   >>> def print_time(a='default'):
> +   ... print("From print_time", time.time(), a)
> ...
> >>> def print_some_times():
> ... print(time.time())
> -   ... s.enter(5, 1, print_time, ())
> -   ... s.enter(10, 1, print_time, ())
> +   ... s.enter(10, 1, print_time)
> +   ... s.enter(5, 2, print_time, argument=('positional',))
> +   ... s.enter(5, 1, print_time, kwargs={'a': 'keyword'})
> ... s.run()
> ... print(time.time())
> ...
> >>> print_some_times()
> 930343690.257
> -   From print_time 930343695.274
> -   From print_time 930343700.273
> +   From print_time 930343695.274 positional
> +   From print_time 930343695.275 keyword
> +   From print_time 930343700.273 default
> 930343700.276
>
>  .. _scheduler-objects:
> @@ -59,7 +62,7 @@
>  :class:`scheduler` instances have the following methods and attributes:
>
>
> -.. method:: scheduler.enterabs(time, priority, action, argument=[],
> kwargs={})
> +.. method:: scheduler.enterabs(time, priority, action, argument=(),
> kwargs={})
>
> Schedule a new event. The *time* argument should be a numeric type
> compatible
> with the return value of the *timefunc* function passed  to the
> constructor.
> @@ -67,8 +70,10 @@
> *priority*.
>
> Executing the event means executing ``action(*argument, **kwargs)``.
> -   *argument* must be a sequence holding the parameters for *action*.
> -   *kwargs* must be a dictionary holding the keyword parameters for
> *action*.
> +   Optional *argument* argument must be a sequence holding the parameters
> +   for *action* if any used.
> +   Optional *kwargs* argument must be a dictionary holding the keyword
> +   parameters for *action* if any used.
>

I don't see how this change improves the documentation. To keep the grammar
correct and just state that the arguments are optional, I would simply
replace "must be" by "is". For example:

  *argument* is a sequence holding the parameters for *action*.

This is short, and since the function signature clearly shows that argument
has a default value, I think it conveys the meaning it should.

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] PEP 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou  wrote:

> On Sat, 29 Dec 2012 19:56:43 +0100
> Lennart Regebro  wrote:
> > On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro 
> wrote:
> >
> > > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver  >wrote:
> > >
> > >> - -Lots for enabling fallback by default except on platforms known
> not to
> > >> have their own database
> > >
> > >
> > > Well, it's the same thing really. If the platform does have a database,
> > > the fallback will not be used.
> > > Of course, there is the case of the database existing on the platform
> > > normally, but somebody for some reason deleting the files, but I don't
> > > think that case deserves an error message.
> > >
> > > I also expect that most platform distributions, such as for Ubuntu,
> will
> > > not include the fallback database, as it will never be used. I'll add
> > > something about that and that we need to raise an error of some sort
> (any
> > > opinions on what?) if no database is found at all.
> > >
> >
> > Actually I already added that, but opinions on what error to raise are
> > still welcome. Currently it says:
> >
> > If no database is found an ``UnknownTimeZoneError`` or subclass
> thereof
> > will
> > be raised with a message explaining that no zoneinfo database can be
> > found,
> > but that you can install one with the ``tzdata-update`` package.
>
> Why should we care about that situation if we *do* provide a database?
> Distributions can decide to exclude some files from their packages, but
> it's their problem, not ours.
>

Yes, but a comprehensible error message is useful even if somebody messed
up the system/configuration.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

[Chris Jerdonek]

On Sat, Dec 29, 2012 at 12:05 PM, Cron Daemon  wrote:
> /home/docs/devguide/documenting.rst:768: WARNING: term not in glossary: 
> bytecode

Why is this warning reported?  I can't reproduce on my system, and on
my system and in the published online docs, the term successfully
links to:

http://docs.python.org/3/glossary.html#term-bytecode

(in the section
http://docs.python.org/devguide/documenting.html#information-units )

--Chris



> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #16641: Fix default values of sched.scheduler.enter arguments were

[Georg Brandl]

On 12/29/2012 08:32 PM, Eli Bendersky wrote:
> 
> 
> 
> On Sat, Dec 29, 2012 at 11:17 AM, serhiy.storchaka  > wrote:
> 
> http://hg.python.org/cpython/rev/1c9c0f92df65
> changeset:   81134:1c9c0f92df65
> branch:  3.3
> parent:  81132:5db0833f135b
> user:Serhiy Storchaka  >
> date:Sat Dec 29 21:13:45 2012 +0200
> summary:
>   Issue #16641: Fix default values of sched.scheduler.enter arguments were
> modifiable.
> 
> files:
>   Doc/library/sched.rst |  23 ++-
>   Lib/sched.py  |   8 ++--
>   Misc/NEWS |   3 +++
>   3 files changed, 23 insertions(+), 11 deletions(-)
> 
> 
> diff --git a/Doc/library/sched.rst b/Doc/library/sched.rst
> --- a/Doc/library/sched.rst
> +++ b/Doc/library/sched.rst
> @@ -36,19 +36,22 @@
> 
> >>> import sched, time
> >>> s = sched.scheduler(time.time, time.sleep)
> -   >>> def print_time(): print("From print_time", time.time())
> +   >>> def print_time(a='default'):
> +   ... print("From print_time", time.time(), a)
> ...
> >>> def print_some_times():
> ... print(time.time())
> -   ... s.enter(5, 1, print_time, ())
> -   ... s.enter(10, 1, print_time, ())
> +   ... s.enter(10, 1, print_time)
> +   ... s.enter(5, 2, print_time, argument=('positional',))
> +   ... s.enter(5, 1, print_time, kwargs={'a': 'keyword'})
> ... s.run()
> ... print(time.time())
> ...
> >>> print_some_times()
> 930343690.257
> -   From print_time 930343695.274
> -   From print_time 930343700.273
> +   From print_time 930343695.274 positional
> +   From print_time 930343695.275 keyword
> +   From print_time 930343700.273 default
> 930343700.276
> 
>  .. _scheduler-objects:
> @@ -59,7 +62,7 @@
>  :class:`scheduler` instances have the following methods and attributes:
> 
> 
> -.. method:: scheduler.enterabs(time, priority, action, argument=[], 
> kwargs={})
> +.. method:: scheduler.enterabs(time, priority, action, argument=(), 
> kwargs={})
> 
> Schedule a new event. The *time* argument should be a numeric type
> compatible
> with the return value of the *timefunc* function passed  to the 
> constructor.
> @@ -67,8 +70,10 @@
> *priority*.
> 
> Executing the event means executing ``action(*argument, **kwargs)``.
> -   *argument* must be a sequence holding the parameters for *action*.
> -   *kwargs* must be a dictionary holding the keyword parameters for 
> *action*.
> +   Optional *argument* argument must be a sequence holding the parameters
> +   for *action* if any used.
> +   Optional *kwargs* argument must be a dictionary holding the keyword
> +   parameters for *action* if any used.
> 
> 
> I don't see how this change improves the documentation. To keep the grammar
> correct and just state that the arguments are optional, I would simply replace
> "must be" by "is". For example:
> 
>   *argument* is a sequence holding the parameters for *action*.
> 
> This is short, and since the function signature clearly shows that argument 
> has
> a default value, I think it conveys the meaning it should.

Hi Eli,

I'm sure we non-native speakers are fine with any improvements you can make
during commit review.

Georg

___
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 (3.3): Issue #16641: Fix default values of sched.scheduler.enter arguments were

[Eli Bendersky]

> > Executing the event means executing ``action(*argument,
> **kwargs)``.
> > -   *argument* must be a sequence holding the parameters for
> *action*.
> > -   *kwargs* must be a dictionary holding the keyword parameters for
> *action*.
> > +   Optional *argument* argument must be a sequence holding the
> parameters
> > +   for *action* if any used.
> > +   Optional *kwargs* argument must be a dictionary holding the
> keyword
> > +   parameters for *action* if any used.
> >
> >
> > I don't see how this change improves the documentation. To keep the
> grammar
> > correct and just state that the arguments are optional, I would simply
> replace
> > "must be" by "is". For example:
> >
> >   *argument* is a sequence holding the parameters for *action*.
> >
> > This is short, and since the function signature clearly shows that
> argument has
> > a default value, I think it conveys the meaning it should.
>
> Hi Eli,
>
> I'm sure we non-native speakers are fine with any improvements you can make
> during commit review.
>
> Georg
>

Georg,

I also wrote a private email to Serhiy proposing to help, but since you
brought this up here: I think that my comment was constructive. What should
have I done differently? Go ahead and modify the phrasing in a separate
commit? I see a couple of problems with that:

1. It can be somewhat disrespectful to a new committer, and I wanted to
reach a consensus first.
2. Serhiy diligently committed this into 3 or 4 different Python branches.
With all due respect, going through the merge/push dance is far above the
effort I'm willing to invest in this.

Eli

P.S. I would argue that you are more native-speaker than myself w.r.t.
English :-)
___
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 (3.3): Issue #16641: Fix default values of sched.scheduler.enter arguments were

[Georg Brandl]

On 12/29/2012 10:44 PM, Eli Bendersky wrote:
> 
> > Executing the event means executing ``action(*argument, 
> **kwargs)``.
> > -   *argument* must be a sequence holding the parameters for 
> *action*.
> > -   *kwargs* must be a dictionary holding the keyword parameters for
> *action*.
> > +   Optional *argument* argument must be a sequence holding the 
> parameters
> > +   for *action* if any used.
> > +   Optional *kwargs* argument must be a dictionary holding the 
> keyword
> > +   parameters for *action* if any used.
> >
> >
> > I don't see how this change improves the documentation. To keep the 
> grammar
> > correct and just state that the arguments are optional, I would simply 
> replace
> > "must be" by "is". For example:
> >
> >   *argument* is a sequence holding the parameters for *action*.
> >
> > This is short, and since the function signature clearly shows that
> argument has
> > a default value, I think it conveys the meaning it should.
> 
> Hi Eli,
> 
> I'm sure we non-native speakers are fine with any improvements you can 
> make
> during commit review.
> 
> Georg
> 
> 
> Georg,
> 
> I also wrote a private email to Serhiy proposing to help, but since you 
> brought
> this up here: I think that my comment was constructive. What should have I 
> done
> differently?

Nothing at all.  In case you read my comment as sarcasm, please don't.  It
probably was a little unreflected.

> Go ahead and modify the phrasing in a separate commit? I see a couple of 
> problems with that:
> 
> 1. It can be somewhat disrespectful to a new committer, and I wanted to reach 
> a
> consensus first.

I would not feel unrespected by someone correcting nits in my English grammar.
(Maybe it would be different for Python grammar :)

> 2. Serhiy diligently committed this into 3 or 4 different Python branches. 
> With
> all due respect, going through the merge/push dance is far above the effort 
> I'm
> willing to invest in this.

I understand.  I probably would have not done it instantly either, but put it
on my todo list and committed when I had some other change as well.

> Eli
> 
> P.S. I would argue that you are more native-speaker than myself w.r.t. 
> English :-)

Then I was mistaken there.  (Are there multiple levels of nativeness? :)  Or is
it because English is half-Germanic?)

cheers,
Georg

___
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 431 Time zone support improvements - Update

[Cameron Simpson]

On 29Dec2012 21:16, Lennart Regebro  wrote:
| On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou  wrote:
| > Why should we care about that situation if we *do* provide a database?
| > Distributions can decide to exclude some files from their packages, but
| > it's their problem, not ours.
| 
| Yes, but a comprehensible error message is useful even if somebody messed
| up the system/configuration.

Couldn't you just agree to augument the exception with some "I looked
here, there and there" information. It avoids a lot of bikeshedding and
makes things clear. You're not diagnosing system misconfiguration, just
saying "I can't find stuff, and here is where I looked".

Cheers,
-- 
Cameron Simpson 
___
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 431 Time zone support improvements - Update

[Terry Reedy]

On 12/29/2012 3:16 PM, Lennart Regebro wrote:


Yes, but a comprehensible error message is useful even if somebody
messed up the system/configuration.


Just reuse whatever exception type you create and add a sensible 
message. Hopefully, it will never be seen.


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

[Python-Dev] test___all__ polluting sys.modules?

[Eli Bendersky]

Hi,

This came up while investigating some test-order-dependency failures in
issue 16076.

test___all__ goes over modules that have `__all__` in them and does 'from
 import *' on them. This leaves a lot of modules in sys.modules,
which may interfere with some tests that do fancy things with sys,modules.
In particular, the ElementTree tests have trouble with it because they
carefully set up the imports to get the C or the Python version of etree
(see issues 15083 and 15075).

Would it make sense to save the sys.modules state and restore it in
test___all__ so that sys.modules isn't affected by this test?

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] test___all__ polluting sys.modules?

[Benjamin Peterson]

2012/12/29 Eli Bendersky :
> Hi,
>
> This came up while investigating some test-order-dependency failures in
> issue 16076.
>
> test___all__ goes over modules that have `__all__` in them and does 'from
>  import *' on them. This leaves a lot of modules in sys.modules,
> which may interfere with some tests that do fancy things with sys,modules.
> In particular, the ElementTree tests have trouble with it because they
> carefully set up the imports to get the C or the Python version of etree
> (see issues 15083 and 15075).
>
> Would it make sense to save the sys.modules state and restore it in
> test___all__ so that sys.modules isn't affected by this test?

Sounds reasonable to me.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test___all__ polluting sys.modules?

[Andrew Svetlov]

See (unfinished but trivial enough) http://bugs.python.org/issue14715
for proposed way to modules/importsystem cleanup

On Sun, Dec 30, 2012 at 2:31 AM, Eli Bendersky  wrote:
> Hi,
>
> This came up while investigating some test-order-dependency failures in
> issue 16076.
>
> test___all__ goes over modules that have `__all__` in them and does 'from
>  import *' on them. This leaves a lot of modules in sys.modules,
> which may interfere with some tests that do fancy things with sys,modules.
> In particular, the ElementTree tests have trouble with it because they
> carefully set up the imports to get the C or the Python version of etree
> (see issues 15083 and 15075).
>
> Would it make sense to save the sys.modules state and restore it in
> test___all__ so that sys.modules isn't affected by this test?
>
> 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/andrew.svetlov%40gmail.com
>



-- 
Thanks,
Andrew Svetlov
___
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] test___all__ polluting sys.modules?

[Eli Bendersky]

On Sat, Dec 29, 2012 at 4:46 PM, Benjamin Peterson wrote:

> 2012/12/29 Eli Bendersky :
> > Hi,
> >
> > This came up while investigating some test-order-dependency failures in
> > issue 16076.
> >
> > test___all__ goes over modules that have `__all__` in them and does 'from
> >  import *' on them. This leaves a lot of modules in sys.modules,
> > which may interfere with some tests that do fancy things with
> sys,modules.
> > In particular, the ElementTree tests have trouble with it because they
> > carefully set up the imports to get the C or the Python version of etree
> > (see issues 15083 and 15075).
> >
> > Would it make sense to save the sys.modules state and restore it in
> > test___all__ so that sys.modules isn't affected by this test?
>
> Sounds reasonable to me.
>

Thanks. http://bugs.python.org/issue16817

Eli



>
> --
> Regards,
> Benjamin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] question about packaging

[Vinay Sajip]

> On Dec 29, 2012, at 5:47 AM, Antoine Pitrou wrote:
> > The current effort seems to be distlib, Vinay's project to gather the
> > "good parts" of packaging and distutils as a library API:
> > http://packages.python.org/distlib/
> > (there's an active bitbucket repo)

See

https://bitbucket.org/vinay.sajip/distlib/

for the latest code, which is periodically pushed to

http://hg.python.org/distlib/

The latest documentation is at

https://distlib.readthedocs.org/en/latest/

While distlib focuses on the packaging PEPs and standardised formats, it is
intended to be possible to build packaging systems on top of it. Compared to
distutils2, distlib aims to make it easier to transition from existing
packaging infrastructure and tools (distutils, setuptools/distribute).

Some of the PEPs are still in flux (e.g. PEP 426, PEP 427).

Regards,

Vinay Sajip

___
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] question about packaging

[Vinay Sajip]

Antonio Cavallo  cavallinux.eu> writes:

> Correct if I'm wrong but distlib isn't targeting resources managent? 
> distutils is targeted to distribute python modules/packages instead; 
> small differences but on the field they really mean different things.

distlib is intended to target more than resource management, but it's not a
full-blown packaging system. Rather, it's intended to implement common pieces
of functionality needed by packaging systems in a hopefully non-controversial
and useful way.
 
> distlib is under http://hg.python.org/distlib too :O

Actually the BitBucket repo is more active and readthedocs has the latest docs,
but I do periodically update the above repo on hg.python.org.

Regards,

Vinay Sajip

___
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] test___all__ polluting sys.modules?

[Nick Coghlan]

On Sun, Dec 30, 2012 at 10:46 AM, Benjamin Peterson  wrote:
> 2012/12/29 Eli Bendersky :
>> Hi,
>>
>> This came up while investigating some test-order-dependency failures in
>> issue 16076.
>>
>> test___all__ goes over modules that have `__all__` in them and does 'from
>>  import *' on them. This leaves a lot of modules in sys.modules,
>> which may interfere with some tests that do fancy things with sys,modules.
>> In particular, the ElementTree tests have trouble with it because they
>> carefully set up the imports to get the C or the Python version of etree
>> (see issues 15083 and 15075).
>>
>> Would it make sense to save the sys.modules state and restore it in
>> test___all__ so that sys.modules isn't affected by this test?
>
> Sounds reasonable to me.

I've tried this as an inherent property of regrtest before (to resolve
some problems with test_pydoc), and it didn't work - we have too many
modules with non-local side effects (IIRC, mostly related to the copy
and pickle registries).

Given that it checks the whole standard library, test___all__ is
likely to run into the same problem.

Hence test.support.import_fresh_module - it can ensure you get the
module you want, regardless of the preexisting contents of
sys.modules. 
(http://docs.python.org/dev/library/test#test.support.import_fresh_module)

Cheers,
Nick.




-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 11:55 PM, Cameron Simpson  wrote:

> On 29Dec2012 21:16, Lennart Regebro  wrote:
> | On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou 
> wrote:
> | > Why should we care about that situation if we *do* provide a database?
> | > Distributions can decide to exclude some files from their packages, but
> | > it's their problem, not ours.
> |
> | Yes, but a comprehensible error message is useful even if somebody messed
> | up the system/configuration.
>
> Couldn't you just agree to augument the exception with some "I looked
> here, there and there" information. It avoids a lot of bikeshedding and
> makes things clear. You're not diagnosing system misconfiguration, just
> saying "I can't find stuff, and here is where I looked".
>

Since the location of the tzdata-update package isn't a fixed place it's
hard to say "I looked here, there and there", though. I don't think anyone
has suggested making any diagnostics. :-)

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 431 Time zone support improvements - Update

[Lennart Regebro]

On Sat, Dec 29, 2012 at 11:59 PM, Terry Reedy  wrote:

> On 12/29/2012 3:16 PM, Lennart Regebro wrote:
>
>  Yes, but a comprehensible error message is useful even if somebody
>> messed up the system/configuration.
>>
>
> Just reuse whatever exception type you create and add a sensible message.
> Hopefully, it will never be seen.
>

I haven't implemented this, but I suspect the code will in the end look for
the tzdata module, which means that if it doesn't exist, the error raised
is an ImportError.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com