Re: [Python-Dev] Attention Bazaar mirror users

[Stephen J. Turnbull]

David Cournapeau writes:

 > > Er, what are people without access to PPAs doing building Python from
 > > a VCS checkout?
 > 
 > I don't see the link between access to PPA and building Python from
 > sources.

I didn't say "from source", I said "from a VCS checkout".  If using a
*specific* recent official release of a core tool is bureaucratically
infeasible, it would IMO be very unusual if you're allowed to checkout
and build arbitrary versions of Python, rather than using a version
provided by your bureaucrats.

The number of people whose job is *specifically* developing Python, or
developing code that depends on bleeding-edge Python, in such an
environment is surely very small.

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[William Dode]

On 21-02-2009, Stephen J. Turnbull wrote:
> Summary:
>
> Google Docs is easy to use, featureful, and here now.  Since AIUI the
> PEPs eventually need to be hosted at python.org, I see Google Docs as
> an immediate replacement for email transmission of early drafts of
> PEPs, not as a permanent solution to PEP storage.
>
> William Dode writes:
>
> > Isn't it the good oportunity to try a DVCS ?

My point was more to try a DVCS to give food to the 374e pep than to 
resolv the issues you mention.

-- 
William Dodé - http://flibuste.net
Informaticien Indépendant

___
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] Attention Bazaar mirror users

[Martin v. Löwis]

> I didn't say "from source", I said "from a VCS checkout".  If using a
> *specific* recent official release of a core tool is bureaucratically
> infeasible, it would IMO be very unusual if you're allowed to checkout
> and build arbitrary versions of Python, rather than using a version
> provided by your bureaucrats.
> 
> The number of people whose job is *specifically* developing Python, or
> developing code that depends on bleeding-edge Python, in such an
> environment is surely very small.

This completely contradicts with my experience. In a university
environment, students regularly check out software from the source
repository, modify it, and build it, just to learn something by doing
so. Yet, in such an environment, they have little control over their
systems - they cannot install software themselves, but have to ask
the university bureaucrats (which often reject such wishes, unless
they come from a teacher - and often even in that case).

There is no problem with people building their own versions of Python,
though - they do so in their home directories, and OS security
mechanisms prevent them from doing harm to other users.

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] A suggestion: Do proto-PEPs in Google Docs

[Jeroen Ruigrok van der Werven]

-On [20090220 18:51], Guido van Rossum (gu...@python.org) wrote:
>I still don't like wikis for this purpose very much -- a person
>editing effectively grabs a lock on the whole file.

Imagine a Wiki with a cross-polination of Etherpad [1], that would resolve
that complaint.

[1] http://etherpad.com/

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Earth to earth, ashes to ashes, dust to dust...
___
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] Tkinter problem in Python 3

[Klaus Müller]

Hi!
I am the lead developer of SimPy (http://simpy.sourceforge.net) . Currently, I 
am porting SimPy to Python 3.

SimPy provides Tk/Tkinter-based GUI and plot facilities.

I find that "import Tkinter" does not work in Python 3, only "import tkinter".

What are the changes for Tkinter under Python 3?

Thanks for your help!

Klaus Müller___
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] Tkinter problem in Python 3

[Guilherme Polo]

On Sat, Feb 21, 2009 at 7:47 AM, Klaus Müller  wrote:
> Hi!
> I am the lead developer of SimPy (http://simpy.sourceforge.net) . Currently,
> I am porting SimPy to Python 3.
>
> SimPy provides Tk/Tkinter-based GUI and plot facilities.
>
> I find that "import Tkinter" does not work in Python 3, only "import
> tkinter".
>
> What are the changes for Tkinter under Python 3?
>

Tkinter lives in a real package now, named "tkinter". Besides that it
hasn't changed much, but this list is inappropriate for this, may I
ask you to move the questions related to tkinter to the
tkinter-discuss list ?

> Thanks for your help!
>
> Klaus Müller


Regards,

-- 
-- Guilherme H. Polo Goncalves
___
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] Tkinter problem in Python 3

[Quentin Gallet-Gilles]

Hi Klaus,

Tkinter was renamed as part of the stdlib reorganization (see the PEP
3108 :http://www.python.org/dev/peps/pep-3108/#tkinter-packagefor more
details).
The 2to3 tool should handle all those changes automatically, by the way.

Cheers,
Quentin

On Sat, Feb 21, 2009 at 11:47 AM, Klaus Müller  wrote:

>  Hi!
> I am the lead developer of SimPy (http://simpy.sourceforge.net) .
> Currently, I am porting SimPy to Python 3.
>
> SimPy provides Tk/Tkinter-based GUI and plot facilities.
>
> I find that "import Tkinter" does not work in Python 3, only "import
> tkinter".
>
> What are the changes for Tkinter under Python 3?
>
> Thanks for your help!
>
> Klaus Müller
>
> ___
> 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/qgallet%40gmail.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] Attention Bazaar mirror users

[Stephen J. Turnbull]

"Martin v. Löwis" writes:
 > sjt sez:

 > > I didn't say "from source", I said "from a VCS checkout".  If using a
 > > *specific* recent official release of a core tool is bureaucratically
 > > infeasible, it would IMO be very unusual if you're allowed to checkout
 > > and build arbitrary versions of Python, rather than using a version
 > > provided by your bureaucrats.
 > > 
 > > The number of people whose job is *specifically* developing Python, or
 > > developing code that depends on bleeding-edge Python, in such an
 > > environment is surely very small.

 > This completely contradicts with my experience. In a university
 > environment, students regularly check out software from the source
 > repository, modify it, and build it, just to learn something by doing
 > so.

You're ignoring the second paragraph quoted above.  I'm *not* denying
that such environments are common.  The question is "Do developers
*restricted to such environments* really have an impact on Python
development to outweigh the real cost of standardizing on an older
implementation of Bazaar to developers who would be able to use a more
capable version?"  I find it hard to believe that it would be so;
Bazaar performance on a lot of measures was pretty poor in v1.5.  I
also find it hard to believe that there are very many serious
developers who only have access to a school lab or who are misusing
corporate resources to develop Python.[1]

Nor does this problem exist with Mercurial or git; both of those have
more than adequate performance for basic operations with whatever-
version-is-in-Debian-lenny (git 1.5.6 and Mercurial 1.0.1).  So I
don't see much harm to come from letting Bazaar at least put forward
its nice shiny new shoes.  Unless the Barry feels that that would be a
risk to Bazaar's acceptability in the end.  He apparently doesn't
think so, though; rather that the improved performance and
capabilities of recent bzr will make it more attractive to the great
majority of Python developers than an older (more "democratic") bzr
would be.

Besides, if Barry makes this experiment *now* and enough people speak
up that it will make it difficult for them to contribute to Python,
the Bazaar proponents can revert to an older version of Bazaar before
a final decision is made.



Footnotes: 
[1]  If it's their job to do so, and Python requires 1.12 to check
out and push to the official sources, won't their bosses push to get
the 1.12 PPA approved?  I would estimate at least 6 months lead time
before the SVN repo is decommissioned, maybe longer if it's maintained
as a mirror for a while.  That should be enough time to get *that
specific revision* (*not* arbitrary installations!) approved.

___
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] Attention Bazaar mirror users

[Paul Moore]

2009/2/21 Stephen J. Turnbull :
> Besides, if Barry makes this experiment *now* and enough people speak
> up that it will make it difficult for them to contribute to Python,
> the Bazaar proponents can revert to an older version of Bazaar before
> a final decision is made.

In addition, I think it's an interesting experiment in its own right -
are the actions required to allow Bazaar to provide comparable
performance to the other contenders, acceptable to the Python
development community?

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[rdmurray]

On Sat, 21 Feb 2009 at 01:12, Jeff Hall wrote:

Not that I'm expecting to be working on PEPs any time soon, but just as a
different perspective, I would find the effort to open up Google docs to
be a much higher barrier to doing some editing tweaks than the dvcs case.
For the DVCS, I'd just write a little script that would (1) update (2)
open the editor on the file (3) do the commit/push dance when the file
was closed.  So for me it would be as easy as editing the file locally.

So for my work style, a DVCS would be the biggest win.

--RDM


That's funny because I would expect that for most people it's the exact
opposite... just create a gmail account... boom, done... I'm not necessarily
advocating that but just saying that IMO, most people will find google docs
to be the "fastest" and "easiest" solution.


The ease of creating a gmail account has nothing to do with the point
to which I was responding (context which is lost from your reply).
That's setup.  I was responding to a point talking about in-the-moment
workflow.  A browser and a GUI javascript program are slower than a unix
command line based editor such as vim or emacs both to open up and to use.
Thus for me, by using a script to automate the part that the OP suggested
would slow the dvcs user down (the update/commit/push cycle), I make
the dvcs in-the-moment workflow much faster _for me_ than Google Docs.

As I said it's a matter of personal style.  Some people _will_ find
Google Docs easier and more productive than a dvcs.  My point was that
not all people will.

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[Guido van Rossum]

On Sat, Feb 21, 2009 at 6:25 AM,   wrote:
> On Sat, 21 Feb 2009 at 01:12, Jeff Hall wrote:
>>>
>>> Not that I'm expecting to be working on PEPs any time soon, but just as a
>>> different perspective, I would find the effort to open up Google docs to
>>> be a much higher barrier to doing some editing tweaks than the dvcs case.
>>> For the DVCS, I'd just write a little script that would (1) update (2)
>>> open the editor on the file (3) do the commit/push dance when the file
>>> was closed.  So for me it would be as easy as editing the file locally.
>>>
>>> So for my work style, a DVCS would be the biggest win.
>>>
>>> --RDM
>>
>> That's funny because I would expect that for most people it's the exact
>> opposite... just create a gmail account... boom, done... I'm not
>> necessarily
>> advocating that but just saying that IMO, most people will find google
>> docs
>> to be the "fastest" and "easiest" solution.
>
> The ease of creating a gmail account has nothing to do with the point
> to which I was responding (context which is lost from your reply).
> That's setup.  I was responding to a point talking about in-the-moment
> workflow.  A browser and a GUI javascript program are slower than a unix
> command line based editor such as vim or emacs both to open up and to use.
> Thus for me, by using a script to automate the part that the OP suggested
> would slow the dvcs user down (the update/commit/push cycle), I make
> the dvcs in-the-moment workflow much faster _for me_ than Google Docs.
>
> As I said it's a matter of personal style.  Some people _will_ find
> Google Docs easier and more productive than a dvcs.  My point was that
> not all people will.

That's a discussion that can never come to a decent conclusion. We
will never find a solution that works for *everyone*, and IMO we don't
need to bend over backwards to try. I don't doubt for a second that
for *most* people the barrier to using Google Docs is less than the
barrier to using a DVCS, even if when you take a sampling of hard core
open source developers that might not be so clear-cut.

-- 
--Guido van Rossum (home page: http://www.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] Attention Bazaar mirror users

[Martin v. Löwis]

> You're ignoring the second paragraph quoted above.  I'm *not* denying
> that such environments are common.  The question is "Do developers
> *restricted to such environments* really have an impact on Python
> development to outweigh the real cost of standardizing on an older
> implementation of Bazaar to developers who would be able to use a more
> capable version?"

But that's not the question at hand. The question at hand was whether
any of the current users of the Bazaar copy of Python would suffer.

This setup was specifically arranged for developers who have no
immediate impact on Python development, so ignoring the primary target
group of the setup when discussing changes to is is, well,
counter-productive.

> Unless the Barry feels that that would be a
> risk to Bazaar's acceptability in the end.

Whether it is depends on when a DVCS gets selected. If it gets selected
after lenny+1 has been released, I see no problem with requiring version
1.12 (or whatever lenny+1 will then ship with).

> Besides, if Barry makes this experiment *now* and enough people speak
> up that it will make it difficult for them to contribute to Python,
> the Bazaar proponents can revert to an older version of Bazaar before
> a final decision is made.

I agree. Going back might require a reconversion of the subversion
repository, but that might be necessary regardless.

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] Choosing a best practice solution for Python/extension modules

[Jean-Paul Calderone]

On Fri, 20 Feb 2009 13:45:26 -0800, Brett Cannon  wrote:

On Fri, Feb 20, 2009 at 12:53, Aahz  wrote:


On Fri, Feb 20, 2009, Brett Cannon wrote:
> On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:
>> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
>> dan...@stutzbachenterprises.com> wrote:
>>>
>>> A slight change would make it work for modules where only key functions
>>> have been rewritten.  For example, pickle.py could read:
>>>
>>> from _pypickle import *
>>> try: from _pickle import *
>>> except ImportError: pass
>>
>> True, although that still suffers from the problem of overwriting things
>> like __name__, __file__, etc.
>
> Actually, I take that back; the IMPORT_STAR opcode doesn't pull in
anything
> starting with an underscore. So while this alleviates the worry above, it
> does mean that anything that gets rewritten needs to have a name that
does
> not lead with an underscore for this to work. Is that really an
acceptable
> compromise for a simple solution like this?

Doesn't __all__ control this?



If you define it, yes.

But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::

 # _pypickle
 def A(): return _B()
 def _B(): return -13

 # _pickle
 def _B(): return 42

 # pickle
 from _pypickle import *
 try: from _pickle import *
 except ImportError: pass

If you import pickle and call pickle.A() you will get -13 which is not what
you are after.


If pickle and _pypickle are both Python modules, and _pypickle.A is intended
to be used all the time, regardless of whether _pickle is available, then
there's not really any reason to implement A in _pypickle.  Just implement it
in pickle.  Then import whatever optionally fast thing it depends on from
_pickle, if possible, and fall-back to the less fast thing in _pypickle
otherwise.

This is really the same as any other high-level/low-level library split.  It
doesn't matter that in this case, one low-level implementation is provided as
an extension module.  Importing the low-level APIs from another module and
then using them to implement high-level APIs is a pretty common, simple,
well-understood technique which is quite applicable here.

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

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[William Dode]

On 21-02-2009, Guido van Rossum wrote:
> On Sat, Feb 21, 2009 at 6:25 AM,   wrote:
>> On Sat, 21 Feb 2009 at 01:12, Jeff Hall wrote:

 Not that I'm expecting to be working on PEPs any time soon, but just as a
 different perspective, I would find the effort to open up Google docs to
 be a much higher barrier to doing some editing tweaks than the dvcs case.
 For the DVCS, I'd just write a little script that would (1) update (2)
 open the editor on the file (3) do the commit/push dance when the file
 was closed.  So for me it would be as easy as editing the file locally.

 So for my work style, a DVCS would be the biggest win.

 --RDM
>>>
>>> That's funny because I would expect that for most people it's the exact
>>> opposite... just create a gmail account... boom, done... I'm not
>>> necessarily
>>> advocating that but just saying that IMO, most people will find google
>>> docs
>>> to be the "fastest" and "easiest" solution.
>>
>> The ease of creating a gmail account has nothing to do with the point
>> to which I was responding (context which is lost from your reply).
>> That's setup.  I was responding to a point talking about in-the-moment
>> workflow.  A browser and a GUI javascript program are slower than a unix
>> command line based editor such as vim or emacs both to open up and to use.
>> Thus for me, by using a script to automate the part that the OP suggested
>> would slow the dvcs user down (the update/commit/push cycle), I make
>> the dvcs in-the-moment workflow much faster _for me_ than Google Docs.
>>
>> As I said it's a matter of personal style.  Some people _will_ find
>> Google Docs easier and more productive than a dvcs.  My point was that
>> not all people will.
>
> That's a discussion that can never come to a decent conclusion. We
> will never find a solution that works for *everyone*

Maybe not for everyone but maybe a DVCS could work for everythings.  
I mean, work for the code, for the doc, for the peps, for the website...  
And also the same tools for core devs and for occasional contributors.

-- 
William Dodé - http://flibuste.net
Informaticien Indépendant

___
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] Attention Bazaar mirror users

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin v. Löwis wrote:
>> I didn't say "from source", I said "from a VCS checkout".  If using a
>> *specific* recent official release of a core tool is bureaucratically
>> infeasible, it would IMO be very unusual if you're allowed to checkout
>> and build arbitrary versions of Python, rather than using a version
>> provided by your bureaucrats.
>>
>> The number of people whose job is *specifically* developing Python, or
>> developing code that depends on bleeding-edge Python, in such an
>> environment is surely very small.
> 
> This completely contradicts with my experience. In a university
> environment, students regularly check out software from the source
> repository, modify it, and build it, just to learn something by doing
> so. Yet, in such an environment, they have little control over their
> systems - they cannot install software themselves, but have to ask
> the university bureaucrats (which often reject such wishes, unless
> they come from a teacher - and often even in that case).
> 
> There is no problem with people building their own versions of Python,
> though - they do so in their home directories, and OS security
> mechanisms prevent them from doing harm to other users.

Wouldn't such hypothetical core Python developers be able to build and
run their own local copy of bzr, using that self-compiled Python?  Let's
not strain at gnats and swallow camels here.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJoD2c+gerLs4ltQ4RAjglAJ9fgoSD0g9jJm8Kw/Z2PBvyXKYIWQCeL+Xa
lybDHEZyjZxG21inSFsn1W0=
=d02o
-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] Attention Bazaar mirror users

[Martin v. Löwis]

> Wouldn't such hypothetical core Python developers be able to build and
> run their own local copy of bzr, using that self-compiled Python? 

It has been hypothetical for a while, but it never was about core
developers.

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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone wrote:

> On Fri, 20 Feb 2009 13:45:26 -0800, Brett Cannon  wrote:
>
>> On Fri, Feb 20, 2009 at 12:53, Aahz  wrote:
>>
>>  On Fri, Feb 20, 2009, Brett Cannon wrote:
>>> > On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:
>>> >> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
>>> >> dan...@stutzbachenterprises.com> wrote:
>>> >>>
>>> >>> A slight change would make it work for modules where only key
>>> functions
>>> >>> have been rewritten.  For example, pickle.py could read:
>>> >>>
>>> >>> from _pypickle import *
>>> >>> try: from _pickle import *
>>> >>> except ImportError: pass
>>> >>
>>> >> True, although that still suffers from the problem of overwriting
>>> things
>>> >> like __name__, __file__, etc.
>>> >
>>> > Actually, I take that back; the IMPORT_STAR opcode doesn't pull in
>>> anything
>>> > starting with an underscore. So while this alleviates the worry above,
>>> it
>>> > does mean that anything that gets rewritten needs to have a name that
>>> does
>>> > not lead with an underscore for this to work. Is that really an
>>> acceptable
>>> > compromise for a simple solution like this?
>>>
>>> Doesn't __all__ control this?
>>>
>>
>>
>> If you define it, yes.
>>
>> But there is another issue with this: the pure Python code will never call
>> the extension code because the globals will be bound to _pypickle and not
>> _pickle. So if you have something like::
>>
>>  # _pypickle
>>  def A(): return _B()
>>  def _B(): return -13
>>
>>  # _pickle
>>  def _B(): return 42
>>
>>  # pickle
>>  from _pypickle import *
>>  try: from _pickle import *
>>  except ImportError: pass
>>
>> If you import pickle and call pickle.A() you will get -13 which is not
>> what
>> you are after.
>>
>
> If pickle and _pypickle are both Python modules, and _pypickle.A is
> intended
> to be used all the time, regardless of whether _pickle is available, then
> there's not really any reason to implement A in _pypickle.  Just implement
> it
> in pickle.  Then import whatever optionally fast thing it depends on from
> _pickle, if possible, and fall-back to the less fast thing in _pypickle
> otherwise.
>
> This is really the same as any other high-level/low-level library split.
>  It
> doesn't matter that in this case, one low-level implementation is provided
> as
> an extension module.  Importing the low-level APIs from another module and
> then using them to implement high-level APIs is a pretty common, simple,
> well-understood technique which is quite applicable here.


But that doesn't provide a clear way, short of screwing with sys.modules, to
get at just the pure Python implementation for testing when the extensions
are also present. The key point in trying to figure this out is to
facilitate testing since the standard library already uses the import *
trick in a couple of places.

-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] Attention Bazaar mirror users

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > so ignoring the primary target group of the setup when discussing
 > changes to is is, well, counter-productive.

I'm *not* ignoring them; I'm stating a strong belief that the great
majority of them will not be adversely affected by this change.  Since
almost by definition they're not likely to speak up very much, I'm
happy to hear arguments from a qualified observer (such as yourself)
on their behalf.  But 10,000 students who use a VCS for a school
project don't matter.  The question is, how many of them would work on
bleeding edge Python?  Those who won't can't suffer from this change!

On the other hand, every Bazaar-using developer who has a copy of bzr
>= 1.9 is *already* suffering.

 > > Unless the Barry feels that that would be a
 > > risk to Bazaar's acceptability in the end.
 > 
 > Whether it is depends on when a DVCS gets selected. If it gets selected
 > after lenny+1 has been released, I see no problem with requiring version
 > 1.12 (or whatever lenny+1 will then ship with).

I really hope we won't have to wait that long!

___
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] Choosing a best practice solution for Python/extension modules

[glyph]

On 07:07 pm, br...@python.org wrote:
On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone 
wrote:


But there is another issue with this: the pure Python code will never 
call
the extension code because the globals will be bound to _pypickle and 
not

_pickle. So if you have something like::



 # _pypickle
 def A(): return _B()
 def _B(): return -13



 # _pickle
 def _B(): return 42



 # pickle
 from _pypickle import *
 try: from _pickle import *
 except ImportError: pass



This is really the same as any other high-level/low-level
library split.  It doesn't matter that in this case, one
low-level implementation is provided as an extension module.
Importing the low-level APIs from another module and then
using them to implement high-level APIs is a pretty common,
simple, well-understood technique which is quite applicable
here.


But that doesn't provide a clear way, short of screwing with 
sys.modules, to
get at just the pure Python implementation for testing when the 
extensions

are also present. The key point in trying to figure this out is to
facilitate testing since the standard library already uses the import *
trick in a couple of places.


You don't have to screw with sys.modules.  The way I would deal with 
testing this particular interaction would be a setUp that replaces 
pickle._A with _pypickle._A, and a tearDown that restores the original 
one.


Twisted's TestCase has specific support for this.  You would spell it 
like this:


   import _pypickle
   # ...
   testCase.patch(pickle, '_A', _pypickle._A)

You can read more about this method here:

http://python.net/crew/mwh/apidocs/twisted.trial.unittest.TestCase.html#patch
___
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] Choosing a best practice solution for Python/extension modules

[Jean-Paul Calderone]

On Sat, 21 Feb 2009 11:07:07 -0800, Brett Cannon  wrote:

On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone wrote:


On Fri, 20 Feb 2009 13:45:26 -0800, Brett Cannon  wrote:


On Fri, Feb 20, 2009 at 12:53, Aahz  wrote:

 On Fri, Feb 20, 2009, Brett Cannon wrote:

> On Fri, Feb 20, 2009 at 12:37, Brett Cannon  wrote:
>> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
>> dan...@stutzbachenterprises.com> wrote:
>>>
>>> A slight change would make it work for modules where only key
functions
>>> have been rewritten.  For example, pickle.py could read:
>>>
>>> from _pypickle import *
>>> try: from _pickle import *
>>> except ImportError: pass
>>
>> True, although that still suffers from the problem of overwriting
things
>> like __name__, __file__, etc.
>
> Actually, I take that back; the IMPORT_STAR opcode doesn't pull in
anything
> starting with an underscore. So while this alleviates the worry above,
it
> does mean that anything that gets rewritten needs to have a name that
does
> not lead with an underscore for this to work. Is that really an
acceptable
> compromise for a simple solution like this?

Doesn't __all__ control this?




If you define it, yes.

But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to _pypickle and not
_pickle. So if you have something like::

 # _pypickle
 def A(): return _B()
 def _B(): return -13

 # _pickle
 def _B(): return 42

 # pickle
 from _pypickle import *
 try: from _pickle import *
 except ImportError: pass

If you import pickle and call pickle.A() you will get -13 which is not
what
you are after.



If pickle and _pypickle are both Python modules, and _pypickle.A is
intended
to be used all the time, regardless of whether _pickle is available, then
there's not really any reason to implement A in _pypickle.  Just implement
it
in pickle.  Then import whatever optionally fast thing it depends on from
_pickle, if possible, and fall-back to the less fast thing in _pypickle
otherwise.

This is really the same as any other high-level/low-level library split.
 It
doesn't matter that in this case, one low-level implementation is provided
as
an extension module.  Importing the low-level APIs from another module and
then using them to implement high-level APIs is a pretty common, simple,
well-understood technique which is quite applicable here.



But that doesn't provide a clear way, short of screwing with sys.modules, to
get at just the pure Python implementation for testing when the extensions
are also present. The key point in trying to figure this out is to
facilitate testing since the standard library already uses the import *
trick in a couple of places.


"screwing with sys.modules" isn't a goal.  It's a means of achieving a goal,
and not a particularly good one.

I guess I overedited my message, sorry about that.  Originally I included
an example of how to parameterize the high-level API to make it easier to
test (or use) with any implementation one wants.  It went something like
this:

   try:
   import _pickle as _lowlevel
   except ImportError:
   import _pypickle as _lowlevel

   class Pickler:
   def __init__(self, implementation=None):
   if implementation is None:
   implementation = _lowlevel
   self.dump = implementation.dump
   self.load = implementation.load
   ...

Perhaps this isn't /exactly/ how pickle wants to work - I haven't looked at
how the C extension and the Python code fit together - but the general idea
should apply regardless of those details.

Jean-Paul
___
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] Attention Bazaar mirror users

[Martin v. Löwis]

> I'm *not* ignoring them; I'm stating a strong belief that the great
> majority of them will not be adversely affected by this change.  Since
> almost by definition they're not likely to speak up very much, I'm
> happy to hear arguments from a qualified observer (such as yourself)
> on their behalf.  But 10,000 students who use a VCS for a school
> project don't matter.  The question is, how many of them would work on
> bleeding edge Python?  Those who won't can't suffer from this change!

>From my experience, students trying to hack open source software
*always* take the public source repository (if available). Downloading
the latest source release doesn't cross their mind. I'm not talking
about regular school projects. I talk about Joe Random CS student who
wants to do some fun project in his spare time.

By using the DVCS, they can trust that they will be able to track
changes - IIUC, that is supposedly the *major* advantage.

Of course, many of them also have personal laptops these days on
which they do stuff, at least here in Germany, where they can
install whatever it takes.

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] Attention Bazaar mirror users

[Antoine Pitrou]

Stephen J. Turnbull  xemacs.org> writes:
>  > 
>  > Whether it is depends on when a DVCS gets selected. If it gets selected
>  > after lenny+1 has been released, I see no problem with requiring version
>  > 1.12 (or whatever lenny+1 will then ship with).
> 
> I really hope we won't have to wait that long!

There are other DVCSes out there, you don't have to "wait" :)


___
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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 21, 2009, at 7:15 AM, Stephen J. Turnbull wrote:


Besides, if Barry makes this experiment *now* and enough people speak
up that it will make it difficult for them to contribute to Python,
the Bazaar proponents can revert to an older version of Bazaar before
a final decision is made.


I'm going to resist the temptation to respond to every message in this  
thread, but really the point was to put forward the best experience  
with the current experiment.  I actually didn't think there were more  
than a handful of people using the current mirrors  and I didn't  
expect any of them to have a real problem with requiring bzr 1.9.  I  
mean, it can be built and run completely from your own directory if  
need be.  Bazaar is Just Python (well, and a little optional Pyrex).


I'm going to resist the temptation to discuss moving beyond the  
current experimental mirror or the final PEP 374 decision.  The latter  
awaits Brett's analysis and no doubt length and passionate debate  
here.  My own personal prediction is that even if a decision is made  
soon after Pycon (Brett has said it won't happen before), actual  
deployment is months away at best.


I think no matter what DVCS gets chosen, there will be lots of  
operational details to be worked out about actually self-hosting those  
branches to the greatest benefit of Python developers, both core and  
non-core.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaBkZXEjvBPtnXfVAQI4egQAgDgOsVY4xnW34xWCOYZOPUtkzIg/SezM
hc8F4VEA2d8s3E7b9Atn4uRBm6ouI57PvIXSOkSUczXAm13yBGazGeQgTo6+VRzq
lVIc4VzZU48jn4sUWESjfH0ewZEbnojUCrLtPa5mE4BWtfor3XlYNl6DjBQRh73V
4T6BAhg8rIc=
=p3rb
-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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 21, 2009, at 4:57 AM, Martin v. Löwis wrote:


There is no problem with people building their own versions of Python,
though - they do so in their home directories, and OS security
mechanisms prevent them from doing harm to other users.


As should be the case with Bazaar and I assume Mercurial or Git.  I  
just offered up the PPA for folks like me who are root but lazy. :)


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaBk33EjvBPtnXfVAQI4sgP+LST/04wpPdckq++BLt5rpeCNfFomu+Zi
ea/wWcVvaEOe5qX+wBuzV7+hfHpJdf5mjX6o876G2CR3ES9T4wMIZj8NJXpa6fLV
/fioiIgT9/cp5sdtuFtMkN+QPrTYqSkOwoeyEuP1pmxEQLUfMxcb43ipOt/fNRzk
1FVf/g5I5/w=
=Ft/Z
-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] Attention Bazaar mirror users

[Jeroen Ruigrok van der Werven]

-On [20090221 21:30], Barry Warsaw (ba...@python.org) wrote:
>I think no matter what DVCS gets chosen

Isn't that getting ahead of the game? I thought that the choice whether or
not a DVCS gets chosen is part of that PEP?

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Earth to earth, ashes to ashes, dust to dust...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 20, 2009, at 10:56 PM, Stephen J. Turnbull wrote:


(1) and (2) are obvious, I think, and I don't know how much (3) really
matters when the editors are a small group.  But I was surprised by
how much (4), and (5) contributed to my experience working on PEP
0374.  Maybe Brett, Barry, or Alexandre would like to comment?


My only comment is that Google docs did not always work correctly for  
me.  E.g. at some point toward the end of the process, I lost the  
ability to add comments.  But hey, it's a big pile of JavaScript so I  
can understand it'll be buggy. :)


When it did work, it was pretty convenient.  I don't think too many  
PEPs will need that kind of high bandwidth collaborative environment,  
but it's nice to have when you need it.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaBl9nEjvBPtnXfVAQK3hwP/dGqkRvIOZbQLVq3m2e+x632jACisNa8D
s398OU/dLz5ZLI6jMGzBTV4r30RypdlQzI47SzfVb2NS6eEtDEkej1f2TvJUm/uJ
O3ROBgo87rmcd9Yu9tClWJLTLw195N1F0fUoy4GwO8cR0+pWXhiVocaRMFSaMciT
zbWrVfp1ep0=
=l2FD
-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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 21, 2009, at 3:35 PM, Jeroen Ruigrok van der Werven wrote:


-On [20090221 21:30], Barry Warsaw (ba...@python.org) wrote:

I think no matter what DVCS gets chosen


Isn't that getting ahead of the game? I thought that the choice  
whether or

not a DVCS gets chosen is part of that PEP?


It is.

Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaBmLHEjvBPtnXfVAQJ2lAP+MFbyWa0j3ups4LFiyyLMMZ3jUKsaynFr
v7CzOMnZQ4QRQoMyM9wlpQKha0VUUdr3dqS/w6O6fRzIT0ROzj/7I1glsW+4Yh5f
ho1vCp41wZ+zUxjDTchho+4Qjo999w9l5rtn6N/5i2WM/0sut9xLKHEGO+EbJtEN
in+wNbIDuYY=
=Gz+m
-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] Attention Bazaar mirror users

[Paul Moore]

2009/2/21 "Martin v. Löwis" :
>> Wouldn't such hypothetical core Python developers be able to build and
>> run their own local copy of bzr, using that self-compiled Python?
>
> It has been hypothetical for a while, but it never was about core
> developers.

Given that it *is* all hypothetical by now, if someone is interested
in hacking on Python, why should they have to build their own copy of
the DVCS to do so?

Paul.

PS Just for my own information, am I correct in thinking that it is
*only* Bazaar in the (D)VCS world that has this problem, to any real
extent? I know old Mercurial clients can interact with newer servers
(ie, the wire protocol hasn't changed), I'm fairly sure that older
Subversion clients can talk to newer servers (at least, I've never
cared what client version I'm running). I've not heard of this type of
discussion around Git (but my experience is limited). But Bazaar seems
very prone to this "upgrade the server and the clients need to be
upgraded too" cycle.
___
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Sat, Feb 21, 2009 at 11:43,  wrote:

> On 07:07 pm, br...@python.org wrote:
>
>> On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone > >wrote:
>>
>
>  But there is another issue with this: the pure Python code will never call
 the extension code because the globals will be bound to _pypickle and
 not
 _pickle. So if you have something like::

>>>
>   # _pypickle
  def A(): return _B()
  def _B(): return -13

>>>
>   # _pickle
  def _B(): return 42

>>>
>   # pickle
  from _pypickle import *
  try: from _pickle import *
  except ImportError: pass

>>>
>  This is really the same as any other high-level/low-level
>>> library split.  It doesn't matter that in this case, one
>>> low-level implementation is provided as an extension module.
>>> Importing the low-level APIs from another module and then
>>> using them to implement high-level APIs is a pretty common,
>>> simple, well-understood technique which is quite applicable
>>> here.
>>>
>>
>  But that doesn't provide a clear way, short of screwing with sys.modules,
>> to
>> get at just the pure Python implementation for testing when the extensions
>> are also present. The key point in trying to figure this out is to
>> facilitate testing since the standard library already uses the import *
>> trick in a couple of places.
>>
>
> You don't have to screw with sys.modules.  The way I would deal with
> testing this particular interaction would be a setUp that replaces pickle._A
> with _pypickle._A, and a tearDown that restores the original one.
>
> Twisted's TestCase has specific support for this.  You would spell it like
> this:
>
>   import _pypickle
>   # ...
>   testCase.patch(pickle, '_A', _pypickle._A)
>
> You can read more about this method here:
>
>
> http://python.net/crew/mwh/apidocs/twisted.trial.unittest.TestCase.html#patch


My worry with this approach is that while this works nicely if you are only
overriding a single function, having to do this for all functions and
classes in order to make sure you are testing the extension code with all
the extension code instead of intermingled extension/Python code. So a
function that did this automatically for the entire module would be needed,
which is like what I proposed in my use_extension function.

I am seeing two approaches emerging. One is where pickle contains all Python
code and then uses something like use_extension to make sure the original
Python objects are still reachable at some point. This has the drawback that
you have to use some function to make the extensions happen and there is
some extra object storage.

The other approach is having pickle contain code known not to be overridden
by anyone, import _pypickle for stuff that may be overridden, and then
import _pickle for whatever is available. This approach has the perk of
using a standard practice for how to pull in different implementation. But
the drawback, thanks to how globals are bound, is that any code pulled in
from _pickle/_pypickle will not be able to call into other optimized code;
it's a take or leave it once the call chain enters one of those modules as
they will always call the implementations in the module they originate from.

-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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Sat, Feb 21, 2009 at 11:32, Jean-Paul Calderone wrote:

> On Sat, 21 Feb 2009 11:07:07 -0800, Brett Cannon  wrote:
>
>> On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone > >wrote:
>>
>>  On Fri, 20 Feb 2009 13:45:26 -0800, Brett Cannon 
>>> wrote:
>>>
>>>  On Fri, Feb 20, 2009 at 12:53, Aahz  wrote:

  On Fri, Feb 20, 2009, Brett Cannon wrote:

> > On Fri, Feb 20, 2009 at 12:37, Brett Cannon 
> wrote:
> >> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
> >> dan...@stutzbachenterprises.com> wrote:
> >>>
> >>> A slight change would make it work for modules where only key
> functions
> >>> have been rewritten.  For example, pickle.py could read:
> >>>
> >>> from _pypickle import *
> >>> try: from _pickle import *
> >>> except ImportError: pass
> >>
> >> True, although that still suffers from the problem of overwriting
> things
> >> like __name__, __file__, etc.
> >
> > Actually, I take that back; the IMPORT_STAR opcode doesn't pull in
> anything
> > starting with an underscore. So while this alleviates the worry
> above,
> it
> > does mean that anything that gets rewritten needs to have a name that
> does
> > not lead with an underscore for this to work. Is that really an
> acceptable
> > compromise for a simple solution like this?
>
> Doesn't __all__ control this?
>
>

 If you define it, yes.

 But there is another issue with this: the pure Python code will never
 call
 the extension code because the globals will be bound to _pypickle and
 not
 _pickle. So if you have something like::

  # _pypickle
  def A(): return _B()
  def _B(): return -13

  # _pickle
  def _B(): return 42

  # pickle
  from _pypickle import *
  try: from _pickle import *
  except ImportError: pass

 If you import pickle and call pickle.A() you will get -13 which is not
 what
 you are after.


>>> If pickle and _pypickle are both Python modules, and _pypickle.A is
>>> intended
>>> to be used all the time, regardless of whether _pickle is available, then
>>> there's not really any reason to implement A in _pypickle.  Just
>>> implement
>>> it
>>> in pickle.  Then import whatever optionally fast thing it depends on from
>>> _pickle, if possible, and fall-back to the less fast thing in _pypickle
>>> otherwise.
>>>
>>> This is really the same as any other high-level/low-level library split.
>>>  It
>>> doesn't matter that in this case, one low-level implementation is
>>> provided
>>> as
>>> an extension module.  Importing the low-level APIs from another module
>>> and
>>> then using them to implement high-level APIs is a pretty common, simple,
>>> well-understood technique which is quite applicable here.
>>>
>>
>>
>> But that doesn't provide a clear way, short of screwing with sys.modules,
>> to
>> get at just the pure Python implementation for testing when the extensions
>> are also present. The key point in trying to figure this out is to
>> facilitate testing since the standard library already uses the import *
>> trick in a couple of places.
>>
>
> "screwing with sys.modules" isn't a goal.  It's a means of achieving a
> goal,
> and not a particularly good one.
>
> I guess I overedited my message, sorry about that.  Originally I included
> an example of how to parameterize the high-level API to make it easier to
> test (or use) with any implementation one wants.  It went something like
> this:
>
>   try:
>   import _pickle as _lowlevel
>   except ImportError:
>   import _pypickle as _lowlevel
>
>   class Pickler:
>   def __init__(self, implementation=None):
>   if implementation is None:
>   implementation = _lowlevel
>   self.dump = implementation.dump
>   self.load = implementation.load
>   ...
>
> Perhaps this isn't /exactly/ how pickle wants to work - I haven't looked at
> how the C extension and the Python code fit together - but the general idea
> should apply regardless of those details.


But this requires all VMs to either implement as an extension the same
thing, or nothing at all. What if Jython only wants to re-implement 'load'
and not 'dump'?

-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] Attention Bazaar mirror users

[Steven Bethard]

On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore  wrote:
> PS Just for my own information, am I correct in thinking that it is
> *only* Bazaar in the (D)VCS world that has this problem, to any real
> extent? I know old Mercurial clients can interact with newer servers
> (ie, the wire protocol hasn't changed), I'm fairly sure that older
> Subversion clients can talk to newer servers (at least, I've never
> cared what client version I'm running).

I've definitely had an SVN server tell me that I needed to upgrade my
client to 1.5.

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] Choosing a best practice solution for Python/extension modules

[Nick Coghlan]

Brett Cannon wrote:
> 
> 
> On Sat, Feb 21, 2009 at 11:43,  > wrote:
> 
> On 07:07 pm, br...@python.org  wrote:
> 
> On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone
> mailto:exar...@divmod.com>>wrote:
> 
> 
> But there is another issue with this: the pure Python
> code will never call
> the extension code because the globals will be bound to
> _pypickle and not
> _pickle. So if you have something like::
> 
> 
>  # _pypickle
>  def A(): return _B()
>  def _B(): return -13
> 
> 
>  # _pickle
>  def _B(): return 42
> 
> 
>  # pickle
>  from _pypickle import *
>  try: from _pickle import *
>  except ImportError: pass
> 
> 
> This is really the same as any other high-level/low-level
> library split.  It doesn't matter that in this case, one
> low-level implementation is provided as an extension module.
> Importing the low-level APIs from another module and then
> using them to implement high-level APIs is a pretty common,
> simple, well-understood technique which is quite applicable
> here.
> 
> 
> But that doesn't provide a clear way, short of screwing with
> sys.modules, to
> get at just the pure Python implementation for testing when the
> extensions
> are also present. The key point in trying to figure this out is to
> facilitate testing since the standard library already uses the
> import *
> trick in a couple of places.
> 
> 
> You don't have to screw with sys.modules.  The way I would deal with
> testing this particular interaction would be a setUp that replaces
> pickle._A with _pypickle._A, and a tearDown that restores the
> original one.
> 
> Twisted's TestCase has specific support for this.  You would spell
> it like this:
> 
>   import _pypickle
>   # ...
>   testCase.patch(pickle, '_A', _pypickle._A)
> 
> You can read more about this method here:
> 
> 
> http://python.net/crew/mwh/apidocs/twisted.trial.unittest.TestCase.html#patch
> 
> 
> My worry with this approach is that while this works nicely if you are
> only overriding a single function, having to do this for all functions
> and classes in order to make sure you are testing the extension code
> with all the extension code instead of intermingled extension/Python
> code. So a function that did this automatically for the entire module
> would be needed, which is like what I proposed in my use_extension function.
> 
> I am seeing two approaches emerging. One is where pickle contains all
> Python code and then uses something like use_extension to make sure the
> original Python objects are still reachable at some point. This has the
> drawback that you have to use some function to make the extensions
> happen and there is some extra object storage.
> 
> The other approach is having pickle contain code known not to be
> overridden by anyone, import _pypickle for stuff that may be overridden,
> and then import _pickle for whatever is available. This approach has the
> perk of using a standard practice for how to pull in different
> implementation. But the drawback, thanks to how globals are bound, is
> that any code pulled in from _pickle/_pypickle will not be able to call
> into other optimized code; it's a take or leave it once the call chain
> enters one of those modules as they will always call the implementations
> in the module they originate from.

I'd actually say there's a third option which is still viable: continue
with the current Foo/_Foo practice for optimised modules, and provide a
function in test.support to get the original Python version's code out
of Foo.

That actually has the virtue of directly testing that the ImportError
for the missing module is being trapped correctly.

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] Attention Bazaar mirror users

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Feb 21, 2009, at 4:11 PM, Paul Moore wrote:


PS Just for my own information, am I correct in thinking that it is
*only* Bazaar in the (D)VCS world that has this problem, to any real
extent? I know old Mercurial clients can interact with newer servers
(ie, the wire protocol hasn't changed), I'm fairly sure that older
Subversion clients can talk to newer servers (at least, I've never
cared what client version I'm running). I've not heard of this type of
discussion around Git (but my experience is limited). But Bazaar seems
very prone to this "upgrade the server and the clients need to be
upgraded too" cycle.


That's not what we're talking about.  This is a case of older clients  
not understanding a newer repository format.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaCCu3EjvBPtnXfVAQIafgP/VVxkAWhvpyagtYudwWXMTq0ErDZ+GoH4
JvwWHZqpp3/DlMwhXLptNrctaPQtdja5dGilSkVokv75OVYj8MZPiofa7peB2kGG
Bi6pdN9ikf3sMU2PNnw3cCHAesdrSWkCAfjYO+AnXH/jn2PY6NdLLGenOvIOKlUu
66xGyep1bT4=
=DR0/
-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] Attention Bazaar mirror users

[Paul Moore]

2009/2/21 Barry Warsaw :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 21, 2009, at 4:11 PM, Paul Moore wrote:
>
>> PS Just for my own information, am I correct in thinking that it is
>> *only* Bazaar in the (D)VCS world that has this problem, to any real
>> extent? I know old Mercurial clients can interact with newer servers
>> (ie, the wire protocol hasn't changed), I'm fairly sure that older
>> Subversion clients can talk to newer servers (at least, I've never
>> cared what client version I'm running). I've not heard of this type of
>> discussion around Git (but my experience is limited). But Bazaar seems
>> very prone to this "upgrade the server and the clients need to be
>> upgraded too" cycle.
>
> That's not what we're talking about.  This is a case of older clients not
> understanding a newer repository format.

Sorry, I'm confused. Isn't that what I said? Clients (who still use
the - older - version they have at the moment) needing to upgrade to
be able to interact with the public repository (server) if that
repository is upgraded to a newer version? When you say "repository"
and I say "server", are we not discussing the same thing (the Bazaar
branches hosted at code.python.org)?

Paul.
___
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] code.interact() locals + globals?

[Rocky Bernstein]

I notice  code.interact() in Python 2.6 has a parameter for locals but not
globals. Should it?

Ultimately,  *exec* is used underneath so I don't see a technical reason why
it couldn't add a global parameter. Also, although one could pass in a
dictionary that is the merger or update() of locals() and globals(),  this
has a couple of downsides.

First, if the intention is to allow update of local and global variables,
combining the two into a single dictionary wreaks havoc. Even if one doesn't
care about this, when the underlying *exec* is performed it will see
different and wrong values for the functions locals() and globals() among
other problems of this kind.
___
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] Choosing a best practice solution for Python/extension modules

[Aahz]

On Sat, Feb 21, 2009, Brett Cannon wrote:
>
> I am seeing two approaches emerging. One is where pickle contains all
> Python code and then uses something like use_extension to make sure
> the original Python objects are still reachable at some point. This
> has the drawback that you have to use some function to make the
> extensions happen and there is some extra object storage.
>
> The other approach is having pickle contain code known not to
> be overridden by anyone, import _pypickle for stuff that may be
> overridden, and then import _pickle for whatever is available. This
> approach has the perk of using a standard practice for how to pull in
> different implementation. But the drawback, thanks to how globals are
> bound, is that any code pulled in from _pickle/_pypickle will not be
> able to call into other optimized code; it's a take or leave it once
> the call chain enters one of those modules as they will always call
> the implementations in the module they originate from.

To what extent do we care about being able to select Python-only on a
per-module basis, particularly in the face of threaded imports?  That is,
we could have a sys.python_only attribute that gets checked on import.
That's simple and direct, and even allows per-module switching if the
application really cares and import doesn't need to worry about threads.

Alternatively, sys.python_only could be a set, but that gets ugly about
setting from the application.  (The module checks to see whether it's
listed in sys.python_only.)

Maybe we should move this discussion to python-ideas for now to kick
around really oddball suggestions?
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] Choosing a best practice solution for Python/extension modules

[Kevin Teague]

So go ahead and tear this apart so that we can hopefully reach a  
consensus that makes sense so that at least testing can easily be  
done.




If I was developing an application and wanted to deal with two  
different versions of the same library, I would simply make sure that  
the version I wanted to use was first on sys.path. Perhaps something  
such as:


lib/python-3.0/libdynload/ # extension module implementations
lib/python-3.0/libpython/ # pure python implementations

Then in the test suite simply ensure that either the Python  
implementation or the C implementation is first on sys.path. Both  
directories would contain an _pickle.py module, and then pickle.py  
could be changed from:


try:
from _pickle import *
except ImportError:
Pickler, Unpickler = _Pickler, _Unpickler

To just:

from _pickle import Pickler, Unpickler

By default libdynload would be first on sys.path so that extension  
modules would be imported first if available, otherwise it would  
fallback to the pure Python versions. The test suite could then add/ 
remove libdynload from sys.path as needed.


Well, OK, so this is a pretty big change as to how standard lib files  
are structured - so maybe there are quite a few reasons why this isn't  
feasable ... but it does make things a lot simpler and gets rid of the  
need for performing any magic with the loaded modules in the test suite.



___
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] Choosing a best practice solution for Python/extension modules

[Brett Cannon]

On Sat, Feb 21, 2009 at 15:46, Aahz  wrote:

> On Sat, Feb 21, 2009, Brett Cannon wrote:
> >
> > I am seeing two approaches emerging. One is where pickle contains all
> > Python code and then uses something like use_extension to make sure
> > the original Python objects are still reachable at some point. This
> > has the drawback that you have to use some function to make the
> > extensions happen and there is some extra object storage.
> >
> > The other approach is having pickle contain code known not to
> > be overridden by anyone, import _pypickle for stuff that may be
> > overridden, and then import _pickle for whatever is available. This
> > approach has the perk of using a standard practice for how to pull in
> > different implementation. But the drawback, thanks to how globals are
> > bound, is that any code pulled in from _pickle/_pypickle will not be
> > able to call into other optimized code; it's a take or leave it once
> > the call chain enters one of those modules as they will always call
> > the implementations in the module they originate from.
>
> To what extent do we care about being able to select Python-only on a
> per-module basis, particularly in the face of threaded imports?  That is,
> we could have a sys.python_only attribute that gets checked on import.
> That's simple and direct, and even allows per-module switching if the
> application really cares and import doesn't need to worry about threads.
>
> Alternatively, sys.python_only could be a set, but that gets ugly about
> setting from the application.  (The module checks to see whether it's
> listed in sys.python_only.)
>
> Maybe we should move this discussion to python-ideas for now to kick
> around really oddball suggestions?


This is all about testing. If a change is made to some extension code it
should be mirrored in the Python code and vice-versa.

-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] code.interact() locals + globals?

[Brett Cannon]

On Sat, Feb 21, 2009 at 15:20, Rocky Bernstein  wrote:

> I notice  code.interact() in Python 2.6 has a parameter for locals but not
> globals. Should it?
>

What is code.interact()?::

>>> (lambda: None).__code__.interact
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'code' object has no attribute 'interact'

-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] code.interact() locals + globals?

[Brett Cannon]

On Sat, Feb 21, 2009 at 16:59, Brett Cannon  wrote:

>
>
> On Sat, Feb 21, 2009 at 15:20, Rocky Bernstein  wrote:
>
>> I notice  code.interact() in Python 2.6 has a parameter for locals but not
>> globals. Should it?
>>
>
> What is code.interact()?::
>
> >>> (lambda: None).__code__.interact
> Traceback (most recent call last):
>   File "", line 1, in 
> AttributeError: 'code' object has no attribute 'interact'
>

nm, I figured out you mean the code module.

-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] Attention Bazaar mirror users

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Moore wrote:
> 2009/2/21 Barry Warsaw :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Feb 21, 2009, at 4:11 PM, Paul Moore wrote:
>>
>>> PS Just for my own information, am I correct in thinking that it is
>>> *only* Bazaar in the (D)VCS world that has this problem, to any real
>>> extent? I know old Mercurial clients can interact with newer servers
>>> (ie, the wire protocol hasn't changed), I'm fairly sure that older
>>> Subversion clients can talk to newer servers (at least, I've never
>>> cared what client version I'm running). I've not heard of this type of
>>> discussion around Git (but my experience is limited). But Bazaar seems
>>> very prone to this "upgrade the server and the clients need to be
>>> upgraded too" cycle.
>> That's not what we're talking about.  This is a case of older clients not
>> understanding a newer repository format.
> 
> Sorry, I'm confused. Isn't that what I said? Clients (who still use
> the - older - version they have at the moment) needing to upgrade to
> be able to interact with the public repository (server) if that
> repository is upgraded to a newer version? When you say "repository"
> and I say "server", are we not discussing the same thing (the Bazaar
> branches hosted at code.python.org)?

This has been true for a number of cases over the years:  whether the
"repostiory format", or the wire protocol,  sometimes changes which
materially *improve* the user's experience may require upgrading the
client on the user's machine.  In the case of SVN, upgrading to 1.5 gets
vastly better merging support;  in the case ob bzr, the win is
performance when working against a large tree.

Given that all the DVCS support is experimental at this point, nobody is
being *blocked* from hacking on the Python core by Barry's proposed
chnage.  He was trying to find out if *real* users of the bzr tree would
be hurt by the repository format upgrade, rather than hypothetical ones.
 AFAICS, no real user (one already using bzr to work with the Python
tree) has objected.


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.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJoKaz+gerLs4ltQ4RAg4XAJ9zP0HU0S8xeaHsThxJ9/MJgpbztQCeINLH
ar5pu9gP3tXdgHtOf3HGyWU=
=4XLm
-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] Attention Bazaar mirror users

[Steve Holden]

Steven Bethard wrote:
> On Sat, Feb 21, 2009 at 1:11 PM, Paul Moore  wrote:
>> PS Just for my own information, am I correct in thinking that it is
>> *only* Bazaar in the (D)VCS world that has this problem, to any real
>> extent? I know old Mercurial clients can interact with newer servers
>> (ie, the wire protocol hasn't changed), I'm fairly sure that older
>> Subversion clients can talk to newer servers (at least, I've never
>> cared what client version I'm running).
> 
> I've definitely had an SVN server tell me that I needed to upgrade my
> client to 1.5.

Interestingly, I've had 1.4 servers tell me I shouldn't have upgraded my
client to 1.5, which is a little tedious = particularly as the
information comes in the form of a hard-to-decipher error message and a
refusal to work. So much for backward compatibility.

Fortunately I still had the SVN 1.4 client on the Ubuntu machine that
was hosting the Samba shares, so I could use ssh and the command line to
maintain things.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.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] Attention Bazaar mirror users

[David Cournapeau]

On Sat, Feb 21, 2009 at 9:15 PM, Stephen J. Turnbull  wrote:
> "Martin v. Löwis" writes:
>  > sjt sez:
>
>  > > I didn't say "from source", I said "from a VCS checkout".  If using a
>  > > *specific* recent official release of a core tool is bureaucratically
>  > > infeasible, it would IMO be very unusual if you're allowed to checkout
>  > > and build arbitrary versions of Python, rather than using a version
>  > > provided by your bureaucrats.
>  > >
>  > > The number of people whose job is *specifically* developing Python, or
>  > > developing code that depends on bleeding-edge Python, in such an
>  > > environment is surely very small.
>
>  > This completely contradicts with my experience. In a university
>  > environment, students regularly check out software from the source
>  > repository, modify it, and build it, just to learn something by doing
>  > so.
>
> You're ignoring the second paragraph quoted above.  I'm *not* denying
> that such environments are common.  The question is "Do developers
> *restricted to such environments* really have an impact on Python
> development to outweigh the real cost of standardizing on an older
> implementation of Bazaar to developers who would be able to use a more
> capable version?"

That was not the original question. I was just meaning to say that not
being able to install from PPA is not hypothetical, in some of my work
environments, not that it would be significant for the python future
:)

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] Attention Bazaar mirror users

[Martin v. Löwis]

> This has been true for a number of cases over the years:  whether the
> "repostiory format", or the wire protocol,  sometimes changes which
> materially *improve* the user's experience may require upgrading the
> client on the user's machine.  In the case of SVN, upgrading to 1.5 gets
> vastly better merging support;  in the case ob bzr, the win is
> performance when working against a large tree.

The question is whether upgrades on the server force upgrades on the
clients. For subversion, this is not the case: Older clients continue
to work correctly with 1.5 servers - they just can't use the merge
functionality. IIUC, for bzr, this is different: if the repository
format is upgraded, older clients will fail to do anything, not even
a regular checkout.

>  AFAICS, no real user (one already using bzr to work with the Python
> tree) has objected.

Apparently not (assuming David Cournapeau does not actually use bzr)

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] Choosing a best practice solution for Python/extension modules

[Aahz]

On Sat, Feb 21, 2009, Brett Cannon wrote:
> On Sat, Feb 21, 2009 at 15:46, Aahz  wrote:
>> On Sat, Feb 21, 2009, Brett Cannon wrote:
>>>
>>> I am seeing two approaches emerging. One is where pickle contains all
>>> Python code and then uses something like use_extension to make sure
>>> the original Python objects are still reachable at some point. This
>>> has the drawback that you have to use some function to make the
>>> extensions happen and there is some extra object storage.
>>>
>>> The other approach is having pickle contain code known not to
>>> be overridden by anyone, import _pypickle for stuff that may be
>>> overridden, and then import _pickle for whatever is available. This
>>> approach has the perk of using a standard practice for how to pull in
>>> different implementation. But the drawback, thanks to how globals are
>>> bound, is that any code pulled in from _pickle/_pypickle will not be
>>> able to call into other optimized code; it's a take or leave it once
>>> the call chain enters one of those modules as they will always call
>>> the implementations in the module they originate from.
>>
>> To what extent do we care about being able to select Python-only on a
>> per-module basis, particularly in the face of threaded imports?  That is,
>> we could have a sys.python_only attribute that gets checked on import.
>> That's simple and direct, and even allows per-module switching if the
>> application really cares and import doesn't need to worry about threads.
>>
>> Alternatively, sys.python_only could be a set, but that gets ugly about
>> setting from the application.  (The module checks to see whether it's
>> listed in sys.python_only.)
>>
>> Maybe we should move this discussion to python-ideas for now to kick
>> around really oddball suggestions?
> 
> This is all about testing. If a change is made to some extension code it
> should be mirrored in the Python code and vice-versa.

Okay, I don't see how that is a response to my suggestion -- I can
imagine that someone might want to test a combination of pure-Python and
binary libraries.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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