Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

[Martin v. Löwis]

Am 02.07.2010 08:55, schrieb Craig Citro:
>> This question has an easy answer - can you possibly tell the difference?
>>
> 
> Ok, I'm obviously being silly here, but sure you can:

The dis module is deliberately (*) not part of the Python language and
standard library; it's an implementation detail (as is the func_code
attribute, and the code object).

So the question really is: can you tell the difference, using only
mechanisms not explicitly documented as implementation-specific?

Regards,
Martin

(*) Unfortunately, the documentation fails to mention that, probably
because it's too obvious.
___
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] Can Python implementations reject semantically invalid expressions?

[Mark Dickinson]

On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro  wrote:
>
> Ok, I'm obviously being silly here, but sure you can:
>
 dis.dis("raise TypeError()")
>          0 <114>           26977
>          3 <115>            8293
>          6 IMPORT_STAR
>          7 SETUP_EXCEPT    25968 (to 25978)
>         10 <69>
>         11 <114>           28530
>         14 <114>           10536
 dis.dis("1 + '1'")
>          0 <49>
>          1 SLICE+2
>          2 STORE_SLICE+3
>          3 SLICE+2
>          4 <39>
>          5 <49>
>          6 <39>

Whoa.  That's very peculiar looking bytecode.  Is dis.dis behaving as
it should here?
BTW, I think you want 'raise TypeError', not 'raise TypeError()'.

Mark
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[anatoly techtonik]

On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller  wrote:
>
> This migration is far from "rushed". Workflow will need to be
> documented and we need a working hg setup a little while before the
> official migration. Both of those said, I personally think this has
> dragged on long enough.

So, if I understand correctly - there are no Mercurial mirrors for
testing at the moment, so the current step is to create these mirrors
to try releasing 3.2 from them. Development will continue in SVN
repository until everybody is ready for final migration in X weeks
later. Is that right?

-- 
anatoly t.
___
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] Can Python implementations reject semantically invalid expressions?

[Mark Dickinson]

On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson  wrote:
> On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro  wrote:
>>
> dis.dis("raise TypeError()")
>>          0 <114>           26977
>>          3 <115>            8293
>>          6 IMPORT_STAR
>>          7 SETUP_EXCEPT    25968 (to 25978)
>>         10 <69>
>>         11 <114>           28530
>>         14 <114>           10536
> dis.dis("1 + '1'")
>>          0 <49>
>>          1 SLICE+2
>>          2 STORE_SLICE+3
>>          3 SLICE+2
>>          4 <39>
>>          5 <49>
>>          6 <39>
>
> Whoa.  That's very peculiar looking bytecode.  Is dis.dis behaving as
> it should here?

Ah.  I see.  It looks like the string "raise TypeError()" is being
interpreted *directly* as Python bytecode, with no intermediate
compilation.  I don't think this is what you intended.  Try:

>>> dis.dis(compile("raise TypeError", "", "exec"))
  1   0 LOAD_NAME0 (TypeError)
  3 RAISE_VARARGS1
  6 LOAD_CONST   0 (None)
  9 RETURN_VALUE
>>> dis.dis(compile("1 + '1'", "", "exec"))
  1   0 LOAD_CONST   0 (1)
  3 LOAD_CONST   1 ('1')
  6 BINARY_ADD
  7 POP_TOP
  8 LOAD_CONST   2 (None)
 11 RETURN_VALUE


Mark
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Dirkjan Ochtman]

On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull  wrote:
> No, you don't.  You make links to 200MB+ (unless you're on Windows,
> where I don't know how this works).  This is much cheaper than
> copying, though not as cheap as in git.  I don't hesitate to make
> branches in Mercurial.

It can still do hardlinks on Windows, provided the repo is on NTFS
(and I think NTFS supports only hardlinks within the same partition).

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] Mercurial migration readiness

[Tim Golden]

On 02/07/2010 08:25, Dirkjan Ochtman wrote:

On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull  wrote:

No, you don't.  You make links to 200MB+ (unless you're on Windows,
where I don't know how this works).  This is much cheaper than
copying, though not as cheap as in git.  I don't hesitate to make
branches in Mercurial.


It can still do hardlinks on Windows, provided the repo is on NTFS
(and I think NTFS supports only hardlinks within the same partition).


Strictly: on the same volume. (Which will generally but not always amount
to: under the same drive letter)

TJG
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 01.07.2010 23:25, schrieb Doug Hellmann:
> 
> On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:
> 
>> On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik > > wrote:
>>
>> 4. Even if I make patch in my Mercurial clone - you still can't pull
>> it and I have to attach it to tracker. No gain.
>>
>>
>> Was there ever any discussion about hosting the central repository on
>> a site such as bitbucket or github?  I tried searching the python-dev
>> archives but was unable to find much.
> 
> I just set up a PSF account on BitBucket for hosting the Pulse
> newsletter repository. I can assist with setting up a public repository
> for the source under that account, too.

Bitbucket usually uses the "mirror" account for pure mirror repos; but
we can probably use our own as well :)

Georg

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

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

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 02.07.2010 09:27, schrieb anatoly techtonik:
> On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller  wrote:
>>
>> This migration is far from "rushed". Workflow will need to be
>> documented and we need a working hg setup a little while before the
>> official migration. Both of those said, I personally think this has
>> dragged on long enough.
> 
> So, if I understand correctly - there are no Mercurial mirrors for
> testing at the moment,

There are repositories at http://hg.python.org/; the "cpython" one
represents the result of conversion at some point in time.

> so the current step is to create these mirrors
> to try releasing 3.2 from them.

I don't know about "try" -- personally I don't see a difference for
the release procedure, no matter where the source comes from.

I also have no problems releasing a first alpha from SVN, and the
following from Hg.

> Development will continue in SVN
> repository until everybody is ready for final migration in X weeks
> later. Is that right?

No; as soon as we switch, SVN will be read-only.

Georg

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

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

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

[Maciej Fijalkowski]

On Fri, Jul 2, 2010 at 1:20 AM, "Martin v. Löwis"  wrote:
> Am 02.07.2010 08:55, schrieb Craig Citro:
>>> This question has an easy answer - can you possibly tell the difference?
>>>
>>
>> Ok, I'm obviously being silly here, but sure you can:
>
> The dis module is deliberately (*) not part of the Python language and
> standard library; it's an implementation detail (as is the func_code
> attribute, and the code object).
>
> So the question really is: can you tell the difference, using only
> mechanisms not explicitly documented as implementation-specific?
>
> Regards,
> Martin
>
> (*) Unfortunately, the documentation fails to mention that, probably
> because it's too obvious.
>

Even more, Jython and IronPython don't have Python bytecode at all and
they're considered python implementations.

Cheers,
fijal
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 02.07.2010 01:05, schrieb Antoine Pitrou:
> On Thu, 1 Jul 2010 15:26:12 -0700
> Brett Cannon  wrote:
>> 
>> As I said, quick-and-dirty. It will take discussion to decide what we
>> want to ask non-committers to do,
> 
> I don't think we have to ask them to do anything special, as long as
> they can submit their contributions under the form of a patch.
> Whether they use named branches, separate clones, mercurial queues, the
> pbranch extension, or even the basic hg-as-an-svn-synonym workflow you
> suggested should be none of our business, IMO.
> 
> A DVCS allows non-committers to manage (augment, fix, synchronize) their
> patches more easily until they get committed. I don't think it will
> change the committers' work a lot, though. I don't know how Mercurial
> could make the task of committing an outsider's patch significantly
> simpler.

I do: if the outsider creates a patch in a personal branch, he is more
likely to merge with the trunk every now and then as if he creates a
patch once and then puts it on the tracker.

Georg

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

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

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

[Steven D'Aprano]

On Fri, 2 Jul 2010 04:55:10 pm Craig Citro wrote:
> > This question has an easy answer - can you possibly tell the
> > difference?
>
> Ok, I'm obviously being silly here, but sure you can:
> >>> dis.dis("raise TypeError()")
>
>   0 <114>   26977
>   3 <115>8293
>   6 IMPORT_STAR
>   7 SETUP_EXCEPT25968 (to 25978)
>  10 <69>
>  11 <114>   28530
>  14 <114>   10536

Craig, what are you using to get that? When I try it in Python 3.1, I 
get:

TypeError: don't know how to disassemble str objects

How do you get that result?



-- 
Steven D'Aprano
___
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] Can Python implementations reject semantically invalid expressions?

[Mark Dickinson]

On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano  wrote:
> Craig, what are you using to get that? When I try it in Python 3.1, I
> get:
>
> TypeError: don't know how to disassemble str objects
>
> How do you get that result?

As I just discovered (see above), dis.dis is happy to interpret byte
strings (i.e., strings in 2.x, bytes in 3.x) as direct representations
of Python bytecode.

There's also an open feature request[1] to allow text strings as input
in py3k, doing an automatic compile before passing the result to
dis.dis.

Mark

[1] http://bugs.python.org/issue6507
___
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] Can Python implementations reject semantically invalid expressions?

[Nick Coghlan]

On Fri, Jul 2, 2010 at 4:55 PM, Craig Citro  wrote:
> Honestly, though, I'd come down on the side of letting the compiler
> raise an error -- while I understand that it means you have
> *different* behavior, I think it's *preferable* behavior.

But you would be taking a module that will compile and making it uncompilable.

The Python code:

  def f():
return 1 + "1"

has fully defined runtime semantics: when f() is called, it will raise
TypeError. A module containing this code is still perfectly valid
Python (e.g. the Python test suite does that kind of thing a lot in
tests of the core interpreter semantics).

A Python implementation issuing a SyntaxWarning over this would be
fine, but triggering a SyntaxError would not be valid. However, I'd be
inclined to leave this kind of check to tools like pychecker and
pylint.

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Thomas Jollans]

On 07/02/2010 10:33 AM, Georg Brandl wrote:
> Am 02.07.2010 09:27, schrieb anatoly techtonik:
>> On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller  wrote:
>>>
>>> This migration is far from "rushed". Workflow will need to be
>>> documented and we need a working hg setup a little while before the
>>> official migration. Both of those said, I personally think this has
>>> dragged on long enough.
>>
>> So, if I understand correctly - there are no Mercurial mirrors for
>> testing at the moment,
> 
> There are repositories at http://hg.python.org/; the "cpython" one
> represents the result of conversion at some point in time.

http://code.python.org/hg/ looks like a working mercurial mirror of
current CPython svn. It's probably nothing you'd like to switch to as
such since it doesn't replace svn usernames with names/e-mail addressed
(as I gather was planned), but it does get updated.

As one of those potential contributors that are new to the game and
actually know and love Mercurial, I've never actually checked out a
Python subversion branch, and have based the few patches I have written
on http://code.python.org/hg/branches/py3k/

Thomas
___
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] Mercurial migration readiness

[Éric Araujo]

hg.python.org/cpython is a test setup for people working on the
transition. It is not guaranteed to be usable, it usually lags, and it
will be rewritten before the real switch IIRC.

code.python.org/hg is a mirror kept in sync for use by contributors who
don’t want to use Subversion now.

After the switch, hg.python.org/cpython will be the official repo, and
code.python.org/hg will probably be closed.

HTH

Regards

___
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] Mercurial migration readiness

[anatoly techtonik]

On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo  wrote:
> hg.python.org/cpython is a test setup for people working on the
> transition. It is not guaranteed to be usable, it usually lags, and it
> will be rewritten before the real switch IIRC.
>
> code.python.org/hg is a mirror kept in sync for use by contributors who
> don’t want to use Subversion now.
>
> After the switch, hg.python.org/cpython will be the official repo, and
> code.python.org/hg will probably be closed.

Why this transition is not described in PEP?
How code.python.org/hg is synchronized with Subversion?
Why it is not possible to leave code.python.org/hg as is in slave mode
and then realtime replication is ready just switch master/slave over?

-- 
anatoly t.
___
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] Mercurial migration readiness

[Antoine Pitrou]

On Fri, 2 Jul 2010 15:22:44 +0300
anatoly techtonik  wrote:
> On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo  wrote:
> > hg.python.org/cpython is a test setup for people working on the
> > transition. It is not guaranteed to be usable, it usually lags, and it
> > will be rewritten before the real switch IIRC.
> >
> > code.python.org/hg is a mirror kept in sync for use by contributors who
> > don’t want to use Subversion now.
> >
> > After the switch, hg.python.org/cpython will be the official repo, and
> > code.python.org/hg will probably be closed.
> 
> Why this transition is not described in PEP?

Because it's not a transition. It's a mirror. It was put in place
before the hg migration plan was accepted, IIRC.

> How code.python.org/hg is synchronized with Subversion?

What does your question mean exactly? It's a mirror (well, a set of
mirrors) and is synchronized roughly every 5 minutes.

> Why it is not possible to leave code.python.org/hg as is in slave mode
> and then realtime replication is ready just switch master/slave over?

The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs, different
metadata, different branch/clone layout).

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] Mercurial migration readiness

[Fred Drake]

On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
> The two sets of repositories use different conversion tools and rules.
> They have nothing in common (different changeset IDs, different
> metadata, different branch/clone layout).

I'd love to see a more detailed description of this, including why
someone new to Mercurial would choose one over the other.

This information really belongs in www.python.org/dev/ rather than
only in the mailing list.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
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] Mercurial migration readiness

[Stephen J. Turnbull]

anatoly techtonik writes:

 > Why this transition is not described in PEP?

Please reread the whole thread, and the PEP.

PEP 385 is *incomplete* (see the red Warning at the top), and the
original proponent *is not going to have enough time to complete it
soon*.  That being the case, Martin suggested that either we find a
new proponent or postpone the transition to next year.  We're
currently in the process of finding a new proponent and supporting
cast, and determining what, if anything, we're going to do about the
transition over the next few months.

There is no reason at this point to suppose the transition can't be
complete by the end of summer.  However, as always, the devil is in
the details, and one of them may be a showstopper.  We'll just have to
see about that.

___
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] Mercurial migration readiness

[Antoine Pitrou]

On Fri, 2 Jul 2010 09:09:48 -0400
Fred Drake  wrote:

> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
> > The two sets of repositories use different conversion tools and rules.
> > They have nothing in common (different changeset IDs, different
> > metadata, different branch/clone layout).
> 
> I'd love to see a more detailed description of this, including why
> someone new to Mercurial would choose one over the other.
> 
> This information really belongs in www.python.org/dev/ rather than
> only in the mailing list.

I'm not sure. Contributors don't really have to know about the
specifics of the temporary repositories used for conversion tests.
www.python.org/dev/ already points to the stable, up-to-date mirrors; I
don't think it's worth complicating that page.

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[anatoly techtonik]

On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl  wrote:
>>
>> So, if I understand correctly - there are no Mercurial mirrors for
>> testing at the moment,
>
> There are repositories at http://hg.python.org/; the "cpython" one
> represents the result of conversion at some point in time.

What is the problem with realtime synchronization and working with
already up to date Mercurial mirror of central SVN repository?

>> Development will continue in SVN
>> repository until everybody is ready for final migration in X weeks
>> later. Is that right?
>
> No; as soon as we switch, SVN will be read-only.

Why don't allow people who already know Mercurial use Mercurial and
those who prefer Subversion use that. If Mercurial allows to submit to
Subversion - why people can't use that while we writing tutorials and
answering question about workflow?
-- 
anatoly t.
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 02.07.2010 15:48, schrieb anatoly techtonik:
> On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl  wrote:
>>>
>>> So, if I understand correctly - there are no Mercurial mirrors for
>>> testing at the moment,
>>
>> There are repositories at http://hg.python.org/; the "cpython" one
>> represents the result of conversion at some point in time.
> 
> What is the problem with realtime synchronization and working with
> already up to date Mercurial mirror of central SVN repository?

The specifics of the conversion process are not nailed down yet.
Therefore, the exact translation of SVN to Hg commits will change,
and with it the Mercurial revision IDs, for example.

>>> Development will continue in SVN
>>> repository until everybody is ready for final migration in X weeks
>>> later. Is that right?
>>
>> No; as soon as we switch, SVN will be read-only.
> 
> Why don't allow people who already know Mercurial use Mercurial and
> those who prefer Subversion use that. If Mercurial allows to submit to
> Subversion - why people can't use that while we writing tutorials and
> answering question about workflow?

I don't think that we have enough manpower to maintain such a bridge
indefinitely.

Georg

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

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

Re: [Python-Dev] Mercurial migration readiness

[Dirkjan Ochtman]

On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou  wrote:
>> I'd love to see a more detailed description of this, including why
>> someone new to Mercurial would choose one over the other.
>>
>> This information really belongs in www.python.org/dev/ rather than
>> only in the mailing list.
>
> I'm not sure. Contributors don't really have to know about the
> specifics of the temporary repositories used for conversion tests.

Very much agreed.

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[anatoly techtonik]

On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl  wrote:
>>
>> What is the problem with realtime synchronization and working with
>> already up to date Mercurial mirror of central SVN repository?
>
> The specifics of the conversion process are not nailed down yet.
> Therefore, the exact translation of SVN to Hg commits will change,
> and with it the Mercurial revision IDs, for example.

Does anybody here know how Mercurial calculates the IDs? From that I
remember it is author + message + diff content. What can change there?

 Development will continue in SVN
 repository until everybody is ready for final migration in X weeks
 later. Is that right?
>>>
>>> No; as soon as we switch, SVN will be read-only.
>>
>> Why don't allow people who already know Mercurial use Mercurial and
>> those who prefer Subversion use that. If Mercurial allows to submit to
>> Subversion - why people can't use that while we writing tutorials and
>> answering question about workflow?
>
> I don't think that we have enough manpower to maintain such a bridge
> indefinitely.

It doesn't require manpower. It requires automation. Considering that
the biggest problem now is to get sane lossless conversion, we should
elaborate on getting this in place. After that I would still follow
the path of setting realtime mirror for X weeks that could be
replicated by bitbucket, launchpad and other services to see how
people pickup the changes.

As PEP 384 says - the transition is mostly to make lives of outside
contributors easier. Core developers can wait for a while.
-- 
anatoly t.
___
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] Are you ready for Mercurial migration?

[anatoly techtonik]

To shed some light on the readiness of Python community for the switch
I've opened public Google Wave. Please add your opinion if you can and
send this link to other contributors you may know:

https://wave.google.com/wave/waveref/googlewave.com/w+G12NYQbDA

-- 
anatoly t.
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Dirkjan Ochtman]

On Fri, Jul 2, 2010 at 16:17, anatoly techtonik  wrote:
> As PEP 384 says - the transition is mostly to make lives of outside
> contributors easier. Core developers can wait for a while.

I think a lot of the core developers also want this because it makes
their lives better.

Also, several people so far have stated that they wouldn't be
interested in a SVN bridge -- AFAICT you are the only one. If you
really want this, maybe you can set it up and maintain it yourself?
Everything about the repo is freely available, so you can just get it
going.

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Jesse Noller]

On Fri, Jul 2, 2010 at 10:17 AM, anatoly techtonik  wrote:
> On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl  wrote:
>>>
>>> What is the problem with realtime synchronization and working with
>>> already up to date Mercurial mirror of central SVN repository?
>>
>> The specifics of the conversion process are not nailed down yet.
>> Therefore, the exact translation of SVN to Hg commits will change,
>> and with it the Mercurial revision IDs, for example.
>
> Does anybody here know how Mercurial calculates the IDs? From that I
> remember it is author + message + diff content. What can change there?
>
> Development will continue in SVN
> repository until everybody is ready for final migration in X weeks
> later. Is that right?

 No; as soon as we switch, SVN will be read-only.
>>>
>>> Why don't allow people who already know Mercurial use Mercurial and
>>> those who prefer Subversion use that. If Mercurial allows to submit to
>>> Subversion - why people can't use that while we writing tutorials and
>>> answering question about workflow?
>>
>> I don't think that we have enough manpower to maintain such a bridge
>> indefinitely.
>
> It doesn't require manpower. It requires automation. Considering that
> the biggest problem now is to get sane lossless conversion, we should
> elaborate on getting this in place. After that I would still follow
> the path of setting realtime mirror for X weeks that could be
> replicated by bitbucket, launchpad and other services to see how
> people pickup the changes.
>
> As PEP 384 says - the transition is mostly to make lives of outside
> contributors easier. Core developers can wait for a while.

No, we can't. We *have* been waiting.
___
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] Can Python implementations reject semantically invalid expressions?

[Craig Citro]

> Whoa.  That's very peculiar looking bytecode.  Is dis.dis behaving as
> it should here?
> BTW, I think you want 'raise TypeError', not 'raise TypeError()'.
>

Yep, that's embarrassing. I was being lazy: I was expecting different
bytecodes, and I got it ... so I apparently didn't bother to actually
read the bytecodes? It's interesting -- if I'd just had TypeError
instead of TypeError(), I would have found this out, because "raise
TypeError" is not the bytes representation of a valid sequence of
bytecodes. ;)

Anyway, here's what I was going for:

>>> def foo():
... return 1+'1'
...
>>> def bar():
... raise TypeError
...
>>> dis.dis(foo)
  2   0 LOAD_CONST   1 (1)
  3 LOAD_CONST   2 ('1')
  6 BINARY_ADD
  7 RETURN_VALUE
>>> dis.dis(bar)
  2   0 LOAD_GLOBAL  0 (TypeError)
  3 RAISE_VARARGS1
  6 LOAD_CONST   0 (None)
  9 RETURN_VALUE

That said, I totally concede Martin's point -- this is an
implementation-specific thing. It happens that all the major Python
implementations compile to some VM, and I'd bet that these two compile
to different bytecodes on any of them, but that doesn't preclude
another implementation from making a different choice there.

-cc
___
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] Are you ready for Mercurial migration?

[Éric Araujo]

Hello Anatoly

I’m thankful that you give time and energy to the issues raised by the
migration. As a minor contributor, I’m eager for the migration, and I
also find healthy that there is discussion about these things. However,
I think that there is too much discussion right now. I offer some facts
and opinions.

1) The PEP is accepted. Python is migrating to Mercurial and closing the
Subversion repository after lengthy discussion and rounds of feedback.
This is beating a dead horse.

2) Python mailing lists are effective, open to anyone with an email
address, and work with all Web and email clients. Google Wave requires
an account, JavaScript, and learning a new thing. That doesn’t help a
situation where we already lack people and time.

2a) Old tools are not always bad. (Emails works.)

2b) New tools can be helpful, but do not magically solve issues. I can’t
see python-dev moving to Trac or Wave in the coming years, so fighting
for them is not productive.

In a community, it’s important to assume that people have reasons for
their choices, research before jumping to conclusions (e.g. hg uses the
parent changeset ID too to compute the ID of a changeset, so the current
mirror and the new, clean official repo will be incompatible), and say
that everything sucks.

To sum up my opinion: The Mercurial migration will proceed as explained
in the PEP, there are still some areas to discuss, the transition will
be delayed if there’s no committer willing to lead the effort. Debating
agreed issues does not help solving open issues.

Regards

___
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] Are you ready for Mercurial migration?

[Georg Brandl]

Am 02.07.2010 16:29, schrieb anatoly techtonik:
> To shed some light on the readiness of Python community for the switch
> I've opened public Google Wave. Please add your opinion if you can and
> send this link to other contributors you may know:

tl;dr: I failed forcing my notions upon the participants in one particular
medium, let's switch to another and try again.

Georg

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

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

Re: [Python-Dev] Are you ready for Mercurial migration?

[Antoine Pitrou]

On Fri, 2 Jul 2010 17:29:02 +0300
anatoly techtonik  wrote:
> To shed some light on the readiness of Python community for the switch
> I've opened public Google Wave. Please add your opinion if you can and
> send this link to other contributors you may know:

Am I the only one to think this should really stop?

By "this", I mean the flow of complaints and dubious "recommendations"
you send here and on the bug tracker. We are volunteers, we don't need
a boss, especially not one who prefers arguing about workflow rather
than addressing concrete issues.

I'm not sure if other people are finding those (Anatoly's) messages
constructive and insightful. To me it looks like they are wasting the
aggregate signal to noise ratio.

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georg Brandl wrote:
> Am 02.07.2010 15:48, schrieb anatoly techtonik:
>> On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl  wrote:
 So, if I understand correctly - there are no Mercurial mirrors for
 testing at the moment,
>>> There are repositories at http://hg.python.org/; the "cpython" one
>>> represents the result of conversion at some point in time.
>> What is the problem with realtime synchronization and working with
>> already up to date Mercurial mirror of central SVN repository?
> 
> The specifics of the conversion process are not nailed down yet.
> Therefore, the exact translation of SVN to Hg commits will change,
> and with it the Mercurial revision IDs, for example.
> 
 Development will continue in SVN
 repository until everybody is ready for final migration in X weeks
 later. Is that right?
>>> No; as soon as we switch, SVN will be read-only.
>> Why don't allow people who already know Mercurial use Mercurial and
>> those who prefer Subversion use that. If Mercurial allows to submit to
>> Subversion - why people can't use that while we writing tutorials and
>> answering question about workflow?
> 
> I don't think that we have enough manpower to maintain such a bridge
> indefinitely.

The code.python.org/hg mirror has been running for many months now: As a
non-committer, I have been able to use its 2.6 branch and the trunk with
hg to test / develop / submit patches.

Can somebody comment on how much ongoing effort is required to keep that
mirror running?  I know that the hg / git / bzr mirrors I set up for the
repoze SVN repository haven't require any ongoing effort, after the
initial day or two of setup effort.


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

iEYEARECAAYFAkwuARwACgkQ+gerLs4ltQ6rUgCfU2NSdjz+pIY1I95OnpRMU5Fx
22gAn1Zu+KGOaNgYJYJ7c9NKzr3ICxS+
=wIB0
-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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 02.07.2010 16:17, schrieb anatoly techtonik:
> On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl  wrote:
>>>
>>> What is the problem with realtime synchronization and working with
>>> already up to date Mercurial mirror of central SVN repository?
>>
>> The specifics of the conversion process are not nailed down yet.
>> Therefore, the exact translation of SVN to Hg commits will change,
>> and with it the Mercurial revision IDs, for example.
> 
> Does anybody here know how Mercurial calculates the IDs? From that I
> remember it is author + message + diff content. What can change there?

The parents IDs also are part of that hash.  Apart from that, author and
message can change as well, since SVN/CVS-style committer names will be
mapped to Mercurial-style name + email, and the message can have
"[rev ...]" appended or prepended or not.

> Development will continue in SVN
> repository until everybody is ready for final migration in X weeks
> later. Is that right?

 No; as soon as we switch, SVN will be read-only.
>>>
>>> Why don't allow people who already know Mercurial use Mercurial and
>>> those who prefer Subversion use that. If Mercurial allows to submit to
>>> Subversion - why people can't use that while we writing tutorials and
>>> answering question about workflow?
>>
>> I don't think that we have enough manpower to maintain such a bridge
>> indefinitely.
> 
> It doesn't require manpower. It requires automation.

And who, do you think, is going to implement that automation?

> Considering that the biggest problem now is to get sane lossless
> conversion, we should elaborate on getting this in place.

Ah, the mysterious "we".

> After that I would still follow
> the path of setting realtime mirror for X weeks that could be
> replicated by bitbucket, launchpad and other services to see how
> people pickup the changes.
> 
> As PEP 384 says - the transition is mostly to make lives of outside
> contributors easier. Core developers can wait for a while.

Anatoly, I don't know what you are trying to achieve here.  The decision
to switch to Mercurial as soon as possible given our manpower restriction
has been made at PyCon 2009.  Since then, there has been progress, albeit
slow, towards that switch, and now that has come into reach, you start
questioning anything and everything.  This is neither productive, nor
have you shown any willingness to actually *do* something to help.  You
claim you do not have enough time for that; looking at the multitude of
topics you're trying to force a discussion about, I wonder if you couldn't
write one decent patch instead of ten complaining mails, and make both
you and us happier in the process.

Georg

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

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

Re: [Python-Dev] Are you ready for Mercurial migration?

[anatoly techtonik]

Éric, you letter is discouraging. This is not for coredevs, who
already "decided" - it for the rest of the world. I should clarify it
in the first place, but I would like to avoid lengthy debates outside
of the Wave.

> As a minor contributor, I’m eager for the migration,

It is not the question about do you like it or not. It is the question

"Are You ready?"

That means:
Have you tried Mercurial?
Do you understand how it works?
Do you have a workflow ready and tested to start commiting right away?
or
Do you plan to read ~100 page long hginit.com tutorial after *it happens?

-- 
anatoly
___
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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Barry Warsaw]

On Jul 02, 2010, at 11:09 AM, Tres Seaver wrote:

>Can somebody comment on how much ongoing effort is required to keep
>that mirror running?

I'm guess "zero".  Other than uploading new ssh keys, I think our svn master
has been humming along pretty well without intervention.  I know that the bzr
mirrors on Launchpad have been zero effort as well.

-Barry


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

Re: [Python-Dev] Are you ready for Mercurial migration?

[Brian Curtin]

On Fri, Jul 2, 2010 at 10:16, anatoly techtonik  wrote:

> It is not the question about do you like it or not. It is the question
>
>"Are You ready?"
>
> That means:
> Have you tried Mercurial?
>

Yes.


> Do you understand how it works?


Yes.


> Do you have a workflow ready and tested to start commiting right away?
>

My mercurial experience is much less than that of others around here and
with much smaller teams, but I'm comfortable with a few workflows and am
open to learn more.


> or
> Do you plan to read ~100 page long hginit.com tutorial after *it happens?
>

That tutorial is not ~100 pages. It's actually a good tutorial.


Feel free to copy that into Google Wave.
___
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] Are you ready for Mercurial migration?

[Éric Araujo]

> Éric, you letter is discouraging.
That’s the right term. I wanted to discourage you from fruitless endeavors.

> This is not for coredevs, who already "decided" - it for the rest of
> the world.
I don’t think there is a discrepancy between the core devs that want to
keep the power and do what they please, and the community that is never
consulted and unable to express itself. I believe that the core devs are
the first circle of the community and that they strive to make open
technical dicussions and reach decisions for the good of everyone. I
find them open and kind, even if sometimes necessarily stern (e.g. when
answering the same question for the umpteenth time).

> I should clarify it in the first place, but I would like to avoid
> lengthy debates outside of the Wave.
And I would like to keep Python-related discussions on open official
fora that have been working for decades.

>> As a minor contributor, I’m eager for the migration,
> It is not the question about do you like it or not.
That paragraph was just me trying to be positive before expressing my
negative comments.

> It is the question 
> "Are You ready?"
> That means:
> Have you tried Mercurial?
Yes.

> Do you understand how it works?
Yes.

> Do you have a workflow ready and tested to start commiting right away?
Yes. I have a handful of workflows in my belt to address different needs
(one-shot typo fix, feature development, local editions, etc.)

> Do you plan to read ~100 page long hginit.com tutorial after *it happens?
Done. I have read the hg book, information on the wiki, made a lot of
tests, read the PEPs, read the short hginit tutorial, and am willing to
review Python-centered docs.

Regards

___
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] Are you ready for Mercurial migration?

[anatoly techtonik]

Antoine, I value you contribution to `hgsvn` project, and this thread
is not a personal accusation of anybody in making proper transition -
please understand that I would like to see the opinion of people who
preferred not to be involved in lengthy discussions. For personal
pretensions against me - please start a new thread and no hijack.

I am trying to solve the same problem as you are - make the Mercurial
migration, but make it as painless as possible.

On Fri, Jul 2, 2010 at 6:08 PM, Antoine Pitrou  wrote:
>
>> To shed some light on the readiness of Python community for the switch
>> I've opened public Google Wave. Please add your opinion if you can and
>> send this link to other contributors you may know:
>
> Am I the only one to think this should really stop?
>
> By "this", I mean the flow of complaints and dubious "recommendations"
> you send here and on the bug tracker. We are volunteers, we don't need
> a boss, especially not one who prefers arguing about workflow rather
> than addressing concrete issues.
>
> I'm not sure if other people are finding those (Anatoly's) messages
> constructive and insightful. To me it looks like they are wasting the
> aggregate signal to noise ratio.
>
> 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/techtonik%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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Georg Brandl]

Am 02.07.2010 17:09, schrieb Tres Seaver:
> Development will continue in SVN
> repository until everybody is ready for final migration in X weeks
> later. Is that right?
 No; as soon as we switch, SVN will be read-only.
>>> Why don't allow people who already know Mercurial use Mercurial and
>>> those who prefer Subversion use that. If Mercurial allows to submit to
>>> Subversion - why people can't use that while we writing tutorials and
>>> answering question about workflow?
> 
>> I don't think that we have enough manpower to maintain such a bridge
>> indefinitely.
> 
> The code.python.org/hg mirror has been running for many months now: As a
> non-committer, I have been able to use its 2.6 branch and the trunk with
> hg to test / develop / submit patches.
> 
> Can somebody comment on how much ongoing effort is required to keep that
> mirror running?  I know that the hg / git / bzr mirrors I set up for the
> repoze SVN repository haven't require any ongoing effort, after the
> initial day or two of setup effort.

As Barry says, that's not a problem.  What's problematic is the continued
use of the current Subversion setup as a read-write bridge to the Mercurial
repo, once the switch to Mercurial as the main platform has happened.

Georg

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

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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2010-06-25 - 2010-07-02)
Python tracker at http://bugs.python.org/

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


 2796 open (+44) / 18167 closed (+20) / 20963 total (+64)

Open issues with patches:  1126

Average duration of open issues: 709 days.
Median duration of open issues: 504 days.

Open Issues Breakdown
   open  2763 (+44)
languishing14 ( +0)
pending18 ( +0)

Issues Created Or Reopened (70)
___

assumption about unsigned long byte size in struct module usag 2010-06-25
CLOSED http://bugs.python.org/issue1789reopened mark.dickinson  
 
   patch, easy 

optparse doesn’t disallow adding one-dash long options (“- 2010-06-26
   http://bugs.python.org/issue4640reopened haypo   
 
   

mimetypes.guess_extension result changes after mimetypes.init( 2010-06-26
   http://bugs.python.org/issue4963reopened r.david.murray  
 
   patch, easy 

PyDateTime_IMPORT macro incorrectly marked up  2010-06-26
CLOSED http://bugs.python.org/issue9024reopened belopolsky  
 
   patch   

test_sysconfig failure 2010-06-25
CLOSED http://bugs.python.org/issue9081created  michael.foord   
 
   

warnings.filterwarnings doesn't work with -O   2010-06-25
   http://bugs.python.org/issue9082created  michael.foord   
 
   

At least some Tools utilities are still Python 2   2010-06-25
   http://bugs.python.org/issue9083created  holdenweb   
 
   

vimrc: use matchall() instead of ":match" to allow multiple ma 2010-06-26
   http://bugs.python.org/issue9084created  blueyed 
 
   patch, needs review 

Version number inconsistency in email package  2010-06-28
   http://bugs.python.org/issue9085reopened r.david.murray  
 
   

Wrong linking terminology in windows FAQ   2010-06-26
   http://bugs.python.org/issue9086created  john.miller 
 
   

json docstrings on 3.x still use 'unicode' and 'str'   2010-06-26
   http://bugs.python.org/issue9087created  ezio.melotti
 
   

revert distutils to its 3.1 state  2010-06-26
   http://bugs.python.org/issue9088created  tarek   
 
   

PyNumber_Int is still mentioned in number protocol docs2010-06-27
CLOSED http://bugs.python.org/issue9089created  belopolsky  
 
   

Error code 10035 calling socket.recv() on a socket with a time 2010-06-27
   http://bugs.python.org/issue9090created  ehohenstein 
 
   patch   

str.capitalize() should not lower the rest of the string   2010-06-27
CLOSED http://bugs.python.org/issue9091created  eka 
 
   

static behavior of local variables 2010-06-27
CLOSED http://bugs.python.org/issue9092created  Aslanidi
 
   

Tools/README is out of date2010-06-27
   http://bugs.python.org/issue9093created  belopolsky  
 
   

Make python-m pickletools do something useful  2010-06-27
   http://bugs.python.org/issue9094created  belopolsky  
 
   patch, easy 

patchcheck should handle extr

Re: [Python-Dev] Are you ready for Mercurial migration?

[anatoly techtonik]

On Fri, Jul 2, 2010 at 6:28 PM, Brian Curtin  wrote:
>> Do you plan to read ~100 page long hginit.com tutorial after *it happens?
>
> That tutorial is not ~100 pages. It's actually a good tutorial.

That's why I posted it here, but it still >80 pages in my browser.

> Feel free to copy that into Google Wave.

Thanks for feedback. It appears that I overestimated the
ubiquitousness of Google Wave. It already has some valuable feedback
and I would really prefer to carry out all discussions there.

In particular Gnome project members estimated as very important the
point of publishing instructions about how to use new DVCS workflow
_before_ migration. We don't have this for the moment.
-- 
anatoly t.
___
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] Can Python implementations reject semantically invalid expressions?

[Mark Dickinson]

On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro  wrote:
>> Whoa.  That's very peculiar looking bytecode.  Is dis.dis behaving as
>> it should here?
>> BTW, I think you want 'raise TypeError', not 'raise TypeError()'.
>>
>
> Yep, that's embarrassing. I was being lazy: I was expecting different
> bytecodes, and I got it ... so I apparently didn't bother to actually
> read the bytecodes? It's interesting -- if I'd just had TypeError
> instead of TypeError(), I would have found this out, because "raise
> TypeError" is not the bytes representation of a valid sequence of
> bytecodes. ;)

Ah;  interesting.  Well clearly that's exactly what I meant when I
said 'raise TypeError' was better than 'raise TypeError()'. ;-)

(Actually, I confess to being similarly embarrassed:  I have no idea
*what* I was thinking there, since 'raise TypeError()' is just as
valid, if a little less idiomatic.)

> That said, I totally concede Martin's point -- this is an
> implementation-specific thing. It happens that all the major Python
> implementations compile to some VM, and I'd bet that these two compile
> to different bytecodes on any of them, but that doesn't preclude
> another implementation from making a different choice there.

Agreed.

Mark
___
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] Can Python implementations reject semantically invalid expressions?

[Craig Citro]

> But you would be taking a module that will compile and making it uncompilable.
>

You're absolutely right, and since I definitely *don't* think that the
program "raise TypeError" should cause a CompileError, you could say
it's safer to have a simple rule like "vaild syntax => will compile"
-- it's probably a slippery slope once you start deciding which bits
of semantics raise CompileErrors and which don't.

However, in this particular case, here's a question: *why* would
someone write "return 1 + '1'"? Did they do it *knowing* what would
happen, or because they just didn't realize it was just an error?

 * If they knew what it was going to do, then I'd say shame on them --
they should have just raised a TypeError instead, and anyone who comes
along to read or maintain that code would thank them for the change.
My impression is that we generally try to discourage people from
writing "tricky" code with Python, and this would do exactly that.

 * If, on the other hand, it's an accident, then I think it's a
service to the user to let them know as soon as possible. Here I'm
thinking both of someone new to Python, or even a seasoned pro who
makes a few "quick fixes" before sending some code to someone, and
doesn't happen to test that code path before handing it off.

Either way, I personally prefer the CompileError -- it helps me catch
a stupid mistake if I've made one, and it prevents other people from
writing code I find less clear.

My real motive, though, is that I'd like to have more freedom for
Python implementations, *especially* things that let you make more
decisions at compile-time. (This is no doubt influenced by the fact
that I've spent a lot of time thinking about Cython lately.) In this
case, I see it as a win-win -- it gives more freedom to the folks
writing the implementation, and (personally) I find it more pleasing
as a user. Again, I don't think this *particular* case allows us to do
something awesome behind the scenes with Cython -- but the community
starting to consider changes of this ilk *would* be a big win, I
think.

-cc
___
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] Can Python implementations reject semantically invalid expressions?

[Georg Brandl]

Am 02.07.2010 18:51, schrieb Craig Citro:
>> But you would be taking a module that will compile and making it 
>> uncompilable.
>>
> 
> You're absolutely right, and since I definitely *don't* think that the
> program "raise TypeError" should cause a CompileError, you could say
> it's safer to have a simple rule like "vaild syntax => will compile"
> -- it's probably a slippery slope once you start deciding which bits
> of semantics raise CompileErrors and which don't.
> 
> However, in this particular case, here's a question: *why* would
> someone write "return 1 + '1'"? Did they do it *knowing* what would
> happen, or because they just didn't realize it was just an error?
> 
>  * If they knew what it was going to do, then I'd say shame on them --
> they should have just raised a TypeError instead, and anyone who comes
> along to read or maintain that code would thank them for the change.

"1/0" is much faster to type than "raise SomeError" and serves the same
purpose sometimes for debugging purposes.  Let's not forget that not
all code is written for eternity :)

Georg

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

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

Re: [Python-Dev] Mercurial migration readiness

[Steve Holden]

Fred Drake wrote:
> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
>> The two sets of repositories use different conversion tools and rules.
>> They have nothing in common (different changeset IDs, different
>> metadata, different branch/clone layout).
> 
> I'd love to see a more detailed description of this, including why
> someone new to Mercurial would choose one over the other.
> 
> This information really belongs in www.python.org/dev/ rather than
> only in the mailing list.
> 
+1

As does a recent essay by Eli Bendersky, IMO. I believe it could lower
the barriers for entry into the "non-committer" class of developer. This
should make it easier for people to adapt Python to their own purposes
whether or not they want to contribute to the open source code base, but
also encourage people to investigate the compiler's innards.

http://eli.thegreenplace.net/2010/06/30/python-internals-adding-a-new-statement-to-python/

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] Can Python implementations reject semantically invalid expressions?

[Nick Coghlan]

On Sat, Jul 3, 2010 at 2:51 AM, Craig Citro  wrote:
>> But you would be taking a module that will compile and making it 
>> uncompilable.
>>
>
> You're absolutely right, and since I definitely *don't* think that the
> program "raise TypeError" should cause a CompileError, you could say
> it's safer to have a simple rule like "vaild syntax => will compile"
> -- it's probably a slippery slope once you start deciding which bits
> of semantics raise CompileErrors and which don't.
>
> However, in this particular case, here's a question: *why* would
> someone write "return 1 + '1'"? Did they do it *knowing* what would
> happen, or because they just didn't realize it was just an error?

To test that adding a string to an integer raises TypeError at
runtime. That is, something along the lines of:

  with self.assertRaises(TypeError):
 1 + "1"

If an end user is doing it rather than an implementation's own test
suite... well, I have no idea why anyone else would want to do that :)

> My real motive, though, is that I'd like to have more freedom for
> Python implementations, *especially* things that let you make more
> decisions at compile-time. (This is no doubt influenced by the fact
> that I've spent a lot of time thinking about Cython lately.) In this
> case, I see it as a win-win -- it gives more freedom to the folks
> writing the implementation, and (personally) I find it more pleasing
> as a user. Again, I don't think this *particular* case allows us to do
> something awesome behind the scenes with Cython -- but the community
> starting to consider changes of this ilk *would* be a big win, I
> think.

It's definitely something of a grey area. The existing test suite
would likely fail if "obviously insane" operations between literals
started throwing SyntaxError, but it would be possible to classify
some of those tests as implementation specific. However, an
implementation that did that would need to completely fork any
affected parts of the test suite, since the implementation specific
test decorators won't help protect against failures to compile the
code.

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] Mercurial migration readiness

[Steve Holden]

Stephen J. Turnbull wrote:
> anatoly techtonik writes:
> 
>  > Why this transition is not described in PEP?
> 
> Please reread the whole thread, and the PEP.
> 
> PEP 385 is *incomplete* (see the red Warning at the top), and the
> original proponent *is not going to have enough time to complete it
> soon*.  That being the case, Martin suggested that either we find a
> new proponent or postpone the transition to next year.  We're
> currently in the process of finding a new proponent and supporting
> cast, and determining what, if anything, we're going to do about the
> transition over the next few months.
> 
> There is no reason at this point to suppose the transition can't be
> complete by the end of summer.  However, as always, the devil is in
> the details, and one of them may be a showstopper.  We'll just have to
> see about that.
> 
And, as always, a way to get better insight and help speed the process
along is to join the cast ...

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] Mercurial migration readiness

[Antoine Pitrou]

On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden  wrote:
> Fred Drake wrote:
> > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
> >> The two sets of repositories use different conversion tools and rules.
> >> They have nothing in common (different changeset IDs, different
> >> metadata, different branch/clone layout).
> > 
> > I'd love to see a more detailed description of this, including why
> > someone new to Mercurial would choose one over the other.
> > 
> > This information really belongs in www.python.org/dev/ rather than
> > only in the mailing list.
> > 
> +1
> 
> As does a recent essay by Eli Bendersky, IMO. I believe it could lower
> the barriers for entry into the "non-committer" class of developer. This
> should make it easier for people to adapt Python to their own purposes
> whether or not they want to contribute to the open source code base, but
> also encourage people to investigate the compiler's innards.

With the moratorium on language constructs and builtins (not only in
letter until 3.3, but more generally in spirit), I don't think we should
encourage it at all, for such contributions would surely be rejected.

Rather than fancy syntax propositions or wild semantic
changes/enhancements (such as have often been proposed on
python-ideas), what we need is humbler but more useful work on stdlib
bugs and improvements, as well as documentation and tutorials.

(what's more, those two kinds of contributions are likely to attract
two different kinds of people, which means that people whose syntax
patches get refused won't necessarily start contributing stdlib or
documentation patches...)

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] Mercurial migration readiness (was: Taking over the Mercurial Migration)

[Steve Holden]

Georg Brandl wrote:
> Am 02.07.2010 16:17, schrieb anatoly techtonik:
>> On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl  wrote:
 What is the problem with realtime synchronization and working with
 already up to date Mercurial mirror of central SVN repository?
>>> The specifics of the conversion process are not nailed down yet.
>>> Therefore, the exact translation of SVN to Hg commits will change,
>>> and with it the Mercurial revision IDs, for example.
>> Does anybody here know how Mercurial calculates the IDs? From that I
>> remember it is author + message + diff content. What can change there?
> 
> The parents IDs also are part of that hash.  Apart from that, author and
> message can change as well, since SVN/CVS-style committer names will be
> mapped to Mercurial-style name + email, and the message can have
> "[rev ...]" appended or prepended or not.
> 
>> Development will continue in SVN
>> repository until everybody is ready for final migration in X weeks
>> later. Is that right?
> No; as soon as we switch, SVN will be read-only.
 Why don't allow people who already know Mercurial use Mercurial and
 those who prefer Subversion use that. If Mercurial allows to submit to
 Subversion - why people can't use that while we writing tutorials and
 answering question about workflow?
>>> I don't think that we have enough manpower to maintain such a bridge
>>> indefinitely.
>> It doesn't require manpower. It requires automation.
> 
> And who, do you think, is going to implement that automation?
> 
>> Considering that the biggest problem now is to get sane lossless
>> conversion, we should elaborate on getting this in place.
> 
> Ah, the mysterious "we".
> 
>> After that I would still follow
>> the path of setting realtime mirror for X weeks that could be
>> replicated by bitbucket, launchpad and other services to see how
>> people pickup the changes.
>>
>> As PEP 384 says - the transition is mostly to make lives of outside
>> contributors easier. Core developers can wait for a while.
> 
> Anatoly, I don't know what you are trying to achieve here.  The decision
> to switch to Mercurial as soon as possible given our manpower restriction
> has been made at PyCon 2009.  Since then, there has been progress, albeit
> slow, towards that switch, and now that has come into reach, you start
> questioning anything and everything.  This is neither productive, nor
> have you shown any willingness to actually *do* something to help.  You
> claim you do not have enough time for that; looking at the multitude of
> topics you're trying to force a discussion about, I wonder if you couldn't
> write one decent patch instead of ten complaining mails, and make both
> you and us happier in the process.
> 
+1

That's the spirit, Georg.

Anatoly, I had an email along these lines saved pending transmission,
but I have deleted it now. Let's make things better rather than dwell on
how rotten everything is and how it could be /so/ much better if "we"
would get off our butts and do {stuff}. ;-)

The more {stuff} done I can point to as PSF chairman the easier it will
be to justify raising funds to help make things better still. I'd rather
see devs developing than administering systems.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] Can Python implementations reject semantically invalid expressions?

[Craig Citro]

> "1/0" is much faster to type than "raise SomeError" and serves the same
> purpose sometimes for debugging purposes.  Let's not forget that not
> all code is written for eternity :)
>

Doesn't "raise" do the same thing for just two extra characters?

I agree that not all code lives forever -- but I bet we all have
stories about "debugging code" living on a lot longer than it should
have. ;)

-cc
___
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] Mercurial migration readiness

[Jesse Noller]

On Fri, Jul 2, 2010 at 1:12 PM, Antoine Pitrou  wrote:
> On Fri, 02 Jul 2010 12:55:56 -0400
> Steve Holden  wrote:
>> Fred Drake wrote:
>> > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
>> >> The two sets of repositories use different conversion tools and rules.
>> >> They have nothing in common (different changeset IDs, different
>> >> metadata, different branch/clone layout).
>> >
>> > I'd love to see a more detailed description of this, including why
>> > someone new to Mercurial would choose one over the other.
>> >
>> > This information really belongs in www.python.org/dev/ rather than
>> > only in the mailing list.
>> >
>> +1
>>
>> As does a recent essay by Eli Bendersky, IMO. I believe it could lower
>> the barriers for entry into the "non-committer" class of developer. This
>> should make it easier for people to adapt Python to their own purposes
>> whether or not they want to contribute to the open source code base, but
>> also encourage people to investigate the compiler's innards.
>
> With the moratorium on language constructs and builtins (not only in
> letter until 3.3, but more generally in spirit), I don't think we should
> encourage it at all, for such contributions would surely be rejected.
>
> Rather than fancy syntax propositions or wild semantic
> changes/enhancements (such as have often been proposed on
> python-ideas), what we need is humbler but more useful work on stdlib
> bugs and improvements, as well as documentation and tutorials.
>
> (what's more, those two kinds of contributions are likely to attract
> two different kinds of people, which means that people whose syntax
> patches get refused won't necessarily start contributing stdlib or
> documentation patches...)
>
> Regards
>
> Antoine.

I completely and wholeheartedly agree with Antoine. I'm hoping the
sprints thing will help with this - the stuff outside of the "deep
core" needs a lot more help and TLC.

jesse
___
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] Are you ready for Mercurial migration?

[Steve Holden]

anatoly techtonik wrote:
> On Fri, Jul 2, 2010 at 6:28 PM, Brian Curtin  wrote:
>>> Do you plan to read ~100 page long hginit.com tutorial after *it happens?
>> That tutorial is not ~100 pages. It's actually a good tutorial.
> 
> That's why I posted it here, but it still >80 pages in my browser.
> 
>> Feel free to copy that into Google Wave.
> 
> Thanks for feedback. It appears that I overestimated the
> ubiquitousness of Google Wave. It already has some valuable feedback
> and I would really prefer to carry out all discussions there.
> 
> In particular Gnome project members estimated as very important the
> point of publishing instructions about how to use new DVCS workflow
> _before_ migration. We don't have this for the moment.

My own experience (I was pretty "meh" about it when people were tweeting
"tweet me for an invite to the wave") is that you have to persist, and
learn different habits for each set of collaborators. I suppose I should
approve of it on account of how it improves geek social skills.

If the wave were to result in good documentation about how to *get*
ready that would be an amazingly useful contribution.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] Are you ready for Mercurial migration?

[Steve Holden]

Perhaps at this stage you could actually start producing, then, and use
up a bit less bandwidth on this channel (on this matter, at least) until
you have results to report?

regards
 Steve

anatoly techtonik wrote:
> Antoine, I value you contribution to `hgsvn` project, and this thread
> is not a personal accusation of anybody in making proper transition -
> please understand that I would like to see the opinion of people who
> preferred not to be involved in lengthy discussions. For personal
> pretensions against me - please start a new thread and no hijack.
> 
> I am trying to solve the same problem as you are - make the Mercurial
> migration, but make it as painless as possible.
> 
> On Fri, Jul 2, 2010 at 6:08 PM, Antoine Pitrou  wrote:
>>> To shed some light on the readiness of Python community for the switch
>>> I've opened public Google Wave. Please add your opinion if you can and
>>> send this link to other contributors you may know:
>> Am I the only one to think this should really stop?
>>
>> By "this", I mean the flow of complaints and dubious "recommendations"
>> you send here and on the bug tracker. We are volunteers, we don't need
>> a boss, especially not one who prefers arguing about workflow rather
>> than addressing concrete issues.
>>
>> I'm not sure if other people are finding those (Anatoly's) messages
>> constructive and insightful. To me it looks like they are wasting the
>> aggregate signal to noise ratio.
>>
>> 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/techtonik%40gmail.com
>>


-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] Can Python implementations reject semantically invalid expressions?

[Nick Coghlan]

On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro  wrote:
>> "1/0" is much faster to type than "raise SomeError" and serves the same
>> purpose sometimes for debugging purposes.  Let's not forget that not
>> all code is written for eternity :)
>>
>
> Doesn't "raise" do the same thing for just two extra characters?

No, raise on its own is only valid in an exception handler. Writing
"1/0" is at least somewhat common as an idiom for forcing a
ZeroDivisionError in examples and in test harnesses (I know I have
used it for both of those things many times).

Given the diverse range of uses Python is put to, moving things from
runtime to compile time can definitely have significant unexpected
consequences (hence why many of us would be hesitant to consider an
implementation that made such changes to be an actual Python
implementation).

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] Can Python implementations reject semantically invalid expressions?

[Craig Citro]

> To test that adding a string to an integer raises TypeError at
> runtime. That is, something along the lines of:
>
>  with self.assertRaises(TypeError):
>     1 + "1"
>

Well, this would just mean the test suite would have to change -- that
test would become something like

with self.assertRaises(TypeError):
import operator
operator.add(1, "1")

Of course, checking that the literal syntax now raises a compile error
could be ugly:

with self.assertRaises(CompileError):
eval('1 + "1"')

... or it could move to test_parser. ;)

> If an end user is doing it rather than an implementation's own test
> suite... well, I have no idea why anyone else would want to do that :)
>

Exactly -- and if it's a clear win for users, I don't think "it makes
test-writing harder but not impossible" should really be a
counter-argument. Of course, "there's lots of existing code it would
break" is a very good counter-argument ... maybe Py4k. ;)

> It's definitely something of a grey area. The existing test suite
> would likely fail if "obviously insane" operations between literals
> started throwing SyntaxError, but it would be possible to classify
> some of those tests as implementation specific. However, an
> implementation that did that would need to completely fork any
> affected parts of the test suite, since the implementation specific
> test decorators won't help protect against failures to compile the
> code.
>

Well, I think there's some momentum towards splitting some of the
tests into Python-standard and implementation-specific things, so that
they can get shared between implementations, right? As long as clear
lines are drawn, isn't it just a question of which bucket these tests
go into?

-cc
___
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] Can Python implementations reject semantically invalid expressions?

[Guido van Rossum]

On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan  wrote:
> On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro  wrote:
>>> "1/0" is much faster to type than "raise SomeError" and serves the same
>>> purpose sometimes for debugging purposes.  Let's not forget that not
>>> all code is written for eternity :)
>>>
>>
>> Doesn't "raise" do the same thing for just two extra characters?
>
> No, raise on its own is only valid in an exception handler. Writing
> "1/0" is at least somewhat common as an idiom for forcing a
> ZeroDivisionError in examples and in test harnesses (I know I have
> used it for both of those things many times).
>
> Given the diverse range of uses Python is put to, moving things from
> runtime to compile time can definitely have significant unexpected
> consequences (hence why many of us would be hesitant to consider an
> implementation that made such changes to be an actual Python
> implementation).

+1 on not changing this.

For one, this will most likely break a large amount of 3rd party and
stdlib software -- there are tons of statements like this that are
practically unreachable or intentional.

Second, I don't think it's going to make the kind of difference the OP
is thinking of. Since Python is totally dynamic, and doesn't have
macros, the only cases that would be caught would be things you are
unlikely to type by accident -- like 1/0 or 1+"1". In other languages
that have this behavior, there is usually a benefit where the
arguments involved are *variables* whose type is known to the
compiler, so it will catch things like (simple C example)

#define FOO 0
main() {
  printf("%d\n", 1/FOO);
}

However the equivalent Python

FOO = 0
def main():
  print 1/FOO

cannot be rejected at compile time because there is insufficient
evidence that the value of FOO won't be changed before main() is
called.

I even reject the substitution of "raise ZeroDivisionError" for "1/0"
since (a) nobody cares about such an optimization, and (b) it would
break introspection and invalidate tests. (We have a long history of
constant propagation in expressions causing subtle bugs. This could be
worse.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

[Cesare Di Mauro]

2010/7/2 Guido van Rossum 

> On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan  wrote:
> > On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro 
> wrote:
> >>> "1/0" is much faster to type than "raise SomeError" and serves the same
> >>> purpose sometimes for debugging purposes.  Let's not forget that not
> >>> all code is written for eternity :)
> >>>
> >>
> >> Doesn't "raise" do the same thing for just two extra characters?
> >
> > No, raise on its own is only valid in an exception handler. Writing
> > "1/0" is at least somewhat common as an idiom for forcing a
> > ZeroDivisionError in examples and in test harnesses (I know I have
> > used it for both of those things many times).
> >
> > Given the diverse range of uses Python is put to, moving things from
> > runtime to compile time can definitely have significant unexpected
> > consequences (hence why many of us would be hesitant to consider an
> > implementation that made such changes to be an actual Python
> > implementation).
>
> +1 on not changing this.
>
> For one, this will most likely break a large amount of 3rd party and
> stdlib software -- there are tons of statements like this that are
> practically unreachable or intentional.
>
> Second, I don't think it's going to make the kind of difference the OP
> is thinking of. Since Python is totally dynamic, and doesn't have
> macros, the only cases that would be caught would be things you are
> unlikely to type by accident -- like 1/0 or 1+"1". In other languages
> that have this behavior, there is usually a benefit where the
> arguments involved are *variables* whose type is known to the
> compiler, so it will catch things like (simple C example)
>
> #define FOO 0
> main() {
>  printf("%d\n", 1/FOO);
> }
>
> However the equivalent Python
>
> FOO = 0
> def main():
>  print 1/FOO
>
> cannot be rejected at compile time because there is insufficient
> evidence that the value of FOO won't be changed before main() is
> called.
>
> I even reject the substitution of "raise ZeroDivisionError" for "1/0"
> since (a) nobody cares about such an optimization, and (b) it would
> break introspection and invalidate tests. (We have a long history of
> constant propagation in expressions causing subtle bugs. This could be
> worse.)
>
> --
> --Guido van Rossum (python.org/~guido)
>

from __future__ import compile_checks

Cesare Di Mauro
___
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] Are you ready for Mercurial migration?

[Brett Cannon]

On Fri, Jul 2, 2010 at 08:49, anatoly techtonik  wrote:
> Antoine, I value you contribution to `hgsvn` project, and this thread
> is not a personal accusation of anybody in making proper transition -
> please understand that I would like to see the opinion of people who
> preferred not to be involved in lengthy discussions.

People who choose not to be involved in a lengthy discussion on a
topic and thus most likely be ill-informed should not participate and
expect to be taken seriously. Making statements without having some
decent amount of knowledge on the subject just leads to bad decisions.
In other words, I don't care about the opinion of uninformed
individuals (and I doubt anyone else does either) so you trying to
bring them into this is not helping matters.

This transition has been in the works since roughly December 2008 when
I started evaluating whether moving to a DVCS was beneficial. That has
been in the open either through PEPs or this mailing list, even a
lightning talk at PyCon 2009. When Dirkjan took on the task (all by
himself) to handle the transition that discussion has stayed public,
mostly through emails on python-dev. This has been vetted as publicly
as possible.

So people who wanted to participate when decisions were being made
could have. But having you come in here and say that this needs to be
discussed again is at least unproductive, if not insulting.

This transition will happen once a proper conversion is up and has
been pounded on, as Martin has suggested. And the proper documentation
will be in place before we hit the switch and turn off svn. Yes, it
has been slow, but considering a single individual has been handling
all technical aspects it is to be expected. And in case I have not
said it publicly, I thank Dirkjan for sticking with this after all
this time.

> For personal
> pretensions against me - please start a new thread and no hijack.

Yes hijack. In case you have not noticed practically every reply on
this email thread has said "stop stirring up trouble and try to help."
All you are doing is muckraking at this point. If you want to help, be
constructive instead of trying to drag this transition out and throw
up barriers. We are beyond the point of bringing up alternatives to
how to handle this. Now we just need manpower to fix the final details
so we can get this finished. Letting this thread just go on is not
helping anyone, so we are all trying to kill it before any more people
waste their time with that wave of yours.

>
> I am trying to solve the same problem as you are - make the Mercurial
> migration, but make it as painless as possible.

Then help! Fix the hgsubversion bug that is blocking the transition.
Port the dev FAQ over to Mercurial if you don't want to code. Do
something constructive! But trying to cause us to change plans that
have been moving forward on the scale of years suddenly is not helping
make the transition any less painless. All you are doing is pissing
people off and causing us to have to waste our time telling you to
stop doing what you are doing.

To be totally frank, Anatoly, you need to contribute in a positive way
and without sounding demanding. Maybe you don't mean to sound
demanding, but your emails sometimes come off like you think we should
listen to all of your ideas with no backing of experience here or
enough evidence to support your ideas. And then rehashing old
decisions like this transition, arguing for svn bridges and the like,
isn't helping improve people's perception of you. It's gotten to the
point where I don't want to read your emails. If you keep up with the
way you are interacting with people on this list I for one will add
you to my python-dev blacklist filter (which currently consists of a
single person, so it is not easy to get put on that list) so that I
don't feel angry or frustrated every time I see an email from you.

-Brett

>
> On Fri, Jul 2, 2010 at 6:08 PM, Antoine Pitrou  wrote:
>>
>>> To shed some light on the readiness of Python community for the switch
>>> I've opened public Google Wave. Please add your opinion if you can and
>>> send this link to other contributors you may know:
>>
>> Am I the only one to think this should really stop?
>>
>> By "this", I mean the flow of complaints and dubious "recommendations"
>> you send here and on the bug tracker. We are volunteers, we don't need
>> a boss, especially not one who prefers arguing about workflow rather
>> than addressing concrete issues.
>>
>> I'm not sure if other people are finding those (Anatoly's) messages
>> constructive and insightful. To me it looks like they are wasting the
>> aggregate signal to noise ratio.
>>
>> 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/techtonik%40gmail.com
>>
> ___
> Python-Dev ma

Re: [Python-Dev] Mercurial migration readiness

[Steve Holden]

Antoine Pitrou wrote:
> On Fri, 02 Jul 2010 12:55:56 -0400
> Steve Holden  wrote:
>> Fred Drake wrote:
>>> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
 The two sets of repositories use different conversion tools and rules.
 They have nothing in common (different changeset IDs, different
 metadata, different branch/clone layout).
>>> I'd love to see a more detailed description of this, including why
>>> someone new to Mercurial would choose one over the other.
>>>
>>> This information really belongs in www.python.org/dev/ rather than
>>> only in the mailing list.
>>>
>> +1
>>
>> As does a recent essay by Eli Bendersky, IMO. I believe it could lower
>> the barriers for entry into the "non-committer" class of developer. This
>> should make it easier for people to adapt Python to their own purposes
>> whether or not they want to contribute to the open source code base, but
>> also encourage people to investigate the compiler's innards.
> 
> With the moratorium on language constructs and builtins (not only in
> letter until 3.3, but more generally in spirit), I don't think we should
> encourage it at all, for such contributions would surely be rejected.
> 
> Rather than fancy syntax propositions or wild semantic
> changes/enhancements (such as have often been proposed on
> python-ideas), what we need is humbler but more useful work on stdlib
> bugs and improvements, as well as documentation and tutorials.
> 
> (what's more, those two kinds of contributions are likely to attract
> two different kinds of people, which means that people whose syntax
> patches get refused won't necessarily start contributing stdlib or
> documentation patches...)
> 
The point was not to encourage experimentation with wild syntax variants
(and Bendersky underlines that he knows perfectly well that Python does
not need an "until" statement. THe point is to encourage more people to
understand that what goes on under the hood is comprehensible.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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

[Python-Dev] SVN <-> HG workflow to split Python Library by Module

[anatoly techtonik]

I planned to publish this proposal when it is finally ready and tested
with an assumption that Subversion repository will be online and
up-to-date after Mercurial migration. But recent threads showed that
currently there is no tested mechanism to sync Subversion repository
back with Mercurial, so it will probably quickly outdate, and the
proposal won't have a chance to be evaluated. So now is better than
never.

So, this is a way to split modules from monolithic Subversion
repository into several Mercurial mirrors - one mirror for each module
(or whatever directory structure you like). This will allow to
concentrate your work on only one module at a time ("distutils",
"CGIHTTPServer" etc.) without caring much about anything else.
Exceptionally useful for occasional external "contributors" like me,
and folks on Windows, who don't possess Visual Studio to compile
Python and are forced to use whatever version they have installed to
create and test patches.

Here is a picture if you feel bored -
https://docs.google.com/drawings/edit?id=1c9FDQ27BnaIew_1T7Tr-rFg1OCdPVS9w3TQREOkzyjk&hl=en
An example of the split distutils module -
http://bitbucket.org/techtonik/distutils

The split is not perfect, but the process can be polished - it is the
first version I managed to get only this morning. More important is
that HG repository is incrementally synchronized. The split is not
perfect, because in particular I see that documentation dir is not
sucked in. But it is a working proof on concept you can test yourself
using the code from:
http://bitbucket.org/techtonik/python-split
You will also need patched version of `hgsvn` from
http://bitbucket.org/techtonik/hgsvn

How does it work
-
The module is described as a series of paths inside typical Subversion checkout.
On the first run `refresh.py` script from `python-split` creates
shallow SVN checkout with only required files using
distutils.module.def module definition
Second run of `refresh.py` imports shallow checkout into Mercurial
And the third run imports the rest of the history pulling only
changesets relevant to given paths.

Workflow
-
Diagram showed patches that are pulled from local clones of split
repositories to master Mercurial mirror, but it won't work this way,
because hashes of revisions in direct mirror wont't match hashes in
split repositories - that's why some hash lookup/sync procedure is
needed to correctly process incoming patches. This workflow works with
hash sync only when changes are pushed back to central Subversion
repository from local clones (possibly through another intermediate
normalizing repository). Changes pushed this way are streamlined and
could be downloaded into stable branch of other mirrors as a single
line of development. I borrowed streamlining concept from Go
contribution guide as it really helps to review chaotic Mercurial
commits. http://golang.org/doc/contribute.html#Code_review

Maintaining centralized Subversion repository will require additional
properties to be set, but this is doable. I don't how to make module
split with Mercurial alone.
http://mercurial.selenic.com/wiki/ShallowClone is still a draft (and
complicated one) and Mercurial 1.6 that released today doesn't contain
anything revolutionary to propose an alternative.

I am exhausted.
-- 
anatoly t.
___
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] SVN <-> HG workflow to split Python Library by Module

[Jesse Noller]

On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik  wrote:
> I planned to publish this proposal when it is finally ready and tested
> with an assumption that Subversion repository will be online and
> up-to-date after Mercurial migration. But recent threads showed that
> currently there is no tested mechanism to sync Subversion repository
> back with Mercurial, so it will probably quickly outdate, and the
> proposal won't have a chance to be evaluated. So now is better than
> never.
>
> So, this is a way to split modules from monolithic Subversion
> repository into several Mercurial mirrors - one mirror for each module
> (or whatever directory structure you like). This will allow to
> concentrate your work on only one module at a time ("distutils",
> "CGIHTTPServer" etc.) without caring much about anything else.
> Exceptionally useful for occasional external "contributors" like me,
> and folks on Windows, who don't possess Visual Studio to compile
> Python and are forced to use whatever version they have installed to
> create and test patches.
>
> Here is a picture if you feel bored -
> https://docs.google.com/drawings/edit?id=1c9FDQ27BnaIew_1T7Tr-rFg1OCdPVS9w3TQREOkzyjk&hl=en
> An example of the split distutils module -
> http://bitbucket.org/techtonik/distutils
>
> The split is not perfect, but the process can be polished - it is the
> first version I managed to get only this morning. More important is
> that HG repository is incrementally synchronized. The split is not
> perfect, because in particular I see that documentation dir is not
> sucked in. But it is a working proof on concept you can test yourself
> using the code from:
> http://bitbucket.org/techtonik/python-split
> You will also need patched version of `hgsvn` from
> http://bitbucket.org/techtonik/hgsvn
>
> How does it work
> -
> The module is described as a series of paths inside typical Subversion 
> checkout.
> On the first run `refresh.py` script from `python-split` creates
> shallow SVN checkout with only required files using
> distutils.module.def module definition
> Second run of `refresh.py` imports shallow checkout into Mercurial
> And the third run imports the rest of the history pulling only
> changesets relevant to given paths.
>
> Workflow
> -
> Diagram showed patches that are pulled from local clones of split
> repositories to master Mercurial mirror, but it won't work this way,
> because hashes of revisions in direct mirror wont't match hashes in
> split repositories - that's why some hash lookup/sync procedure is
> needed to correctly process incoming patches. This workflow works with
> hash sync only when changes are pushed back to central Subversion
> repository from local clones (possibly through another intermediate
> normalizing repository). Changes pushed this way are streamlined and
> could be downloaded into stable branch of other mirrors as a single
> line of development. I borrowed streamlining concept from Go
> contribution guide as it really helps to review chaotic Mercurial
> commits. http://golang.org/doc/contribute.html#Code_review
>
> Maintaining centralized Subversion repository will require additional
> properties to be set, but this is doable. I don't how to make module
> split with Mercurial alone.
> http://mercurial.selenic.com/wiki/ShallowClone is still a draft (and
> complicated one) and Mercurial 1.6 that released today doesn't contain
> anything revolutionary to propose an alternative.
>
> I am exhausted.

fwiw - there is a/are plan(s) to break out the stdlib from "core" once
the transition is complete, to better allow re-use between the various
interpreters. I do not think that "lots of small mirrors/repos" for
each library is a net gain. Once the stdlib is broken out; the same
thing you have proposed is achievable (within reason) without a
proliferation of mirrors/repos/etc.

Also, we're not staying on subversion - well, as far I know.

jesse
___
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] SVN <-> HG workflow to split Python Library by Module

[David Stanek]

On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik  wrote:
> I planned to publish this proposal when it is finally ready and tested
> with an assumption that Subversion repository will be online and
> up-to-date after Mercurial migration. But recent threads showed that
> currently there is no tested mechanism to sync Subversion repository
> back with Mercurial, so it will probably quickly outdate, and the
> proposal won't have a chance to be evaluated. So now is better than
> never.
>

I don't think it would be very hard to update a read-only version of
Subversion. It just gets complicated if you plan on committing to both
Subversion and Mercurial.

Does having many little repos add more value than the pain it creates?

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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] Can Python implementations reject semantically invalid expressions?

[Terry Reedy]

On 7/2/2010 12:43 AM, Glyph Lefkowitz wrote:


def f(): return 1 + "1"

instead of compiling something which can't fail to raise an
exception, would that still be a legal Python implementation?


I'd say "no".  Python has defined semantics in this situation: a
TypeError is raised.


The manuals are rather inconsistent about defining the exception 
semantics. Some parts define the exception returned. Other, equivalent 
parts, do not. I should start a separate thread on this when I find the 
examples I once had.


--
Terry Jan Reedy

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

Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module

[Brett Cannon]

On Fri, Jul 2, 2010 at 12:25, anatoly techtonik  wrote:
> I planned to publish this proposal when it is finally ready and tested
> with an assumption that Subversion repository will be online and
> up-to-date after Mercurial migration. But recent threads showed that
> currently there is no tested mechanism to sync Subversion repository
> back with Mercurial, so it will probably quickly outdate, and the
> proposal won't have a chance to be evaluated. So now is better than
> never.
>
> So, this is a way to split modules from monolithic Subversion
> repository into several Mercurial mirrors - one mirror for each module
> (or whatever directory structure you like). This will allow to
> concentrate your work on only one module at a time ("distutils",
> "CGIHTTPServer" etc.) without caring much about anything else.
> Exceptionally useful for occasional external "contributors" like me,
> and folks on Windows, who don't possess Visual Studio to compile
> Python and are forced to use whatever version they have installed to
> create and test patches.

But modules do not live in an isolated world; they are dependent on
changes made to other modules. Isolating them from other modules whose
semantics change during development will lead to skew and improper
patches.

As for Windows users who don't have Visual Studio, there is a free
version that compiles Python fine: http://www.python.org/dev/faq/#id8
.

-Brett


>
> Here is a picture if you feel bored -
> https://docs.google.com/drawings/edit?id=1c9FDQ27BnaIew_1T7Tr-rFg1OCdPVS9w3TQREOkzyjk&hl=en
> An example of the split distutils module -
> http://bitbucket.org/techtonik/distutils
>
> The split is not perfect, but the process can be polished - it is the
> first version I managed to get only this morning. More important is
> that HG repository is incrementally synchronized. The split is not
> perfect, because in particular I see that documentation dir is not
> sucked in. But it is a working proof on concept you can test yourself
> using the code from:
> http://bitbucket.org/techtonik/python-split
> You will also need patched version of `hgsvn` from
> http://bitbucket.org/techtonik/hgsvn
>
> How does it work
> -
> The module is described as a series of paths inside typical Subversion 
> checkout.
> On the first run `refresh.py` script from `python-split` creates
> shallow SVN checkout with only required files using
> distutils.module.def module definition
> Second run of `refresh.py` imports shallow checkout into Mercurial
> And the third run imports the rest of the history pulling only
> changesets relevant to given paths.
>
> Workflow
> -
> Diagram showed patches that are pulled from local clones of split
> repositories to master Mercurial mirror, but it won't work this way,
> because hashes of revisions in direct mirror wont't match hashes in
> split repositories - that's why some hash lookup/sync procedure is
> needed to correctly process incoming patches. This workflow works with
> hash sync only when changes are pushed back to central Subversion
> repository from local clones (possibly through another intermediate
> normalizing repository). Changes pushed this way are streamlined and
> could be downloaded into stable branch of other mirrors as a single
> line of development. I borrowed streamlining concept from Go
> contribution guide as it really helps to review chaotic Mercurial
> commits. http://golang.org/doc/contribute.html#Code_review
>
> Maintaining centralized Subversion repository will require additional
> properties to be set, but this is doable. I don't how to make module
> split with Mercurial alone.
> http://mercurial.selenic.com/wiki/ShallowClone is still a draft (and
> complicated one) and Mercurial 1.6 that released today doesn't contain
> anything revolutionary to propose an alternative.
>
> I am exhausted.
> --
> anatoly t.
> ___
> 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/brett%40python.org
>
___
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] SVN <-> HG workflow to split Python Library by Module

[Georg Brandl]

Am 02.07.2010 22:01, schrieb Jesse Noller:

>> I am exhausted.
> 
> fwiw - there is a/are plan(s) to break out the stdlib from "core" once
> the transition is complete, to better allow re-use between the various
> interpreters. I do not think that "lots of small mirrors/repos" for
> each library is a net gain. Once the stdlib is broken out; the same
> thing you have proposed is achievable (within reason) without a
> proliferation of mirrors/repos/etc.
> 
> Also, we're not staying on subversion - well, as far I know.

At least not parallel to Mercurial.  Definitely.

Georg

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

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

Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module

[Jesse Noller]

On Fri, Jul 2, 2010 at 5:57 PM, Georg Brandl  wrote:
> Am 02.07.2010 22:01, schrieb Jesse Noller:
>
>>> I am exhausted.
>>
>> fwiw - there is a/are plan(s) to break out the stdlib from "core" once
>> the transition is complete, to better allow re-use between the various
>> interpreters. I do not think that "lots of small mirrors/repos" for
>> each library is a net gain. Once the stdlib is broken out; the same
>> thing you have proposed is achievable (within reason) without a
>> proliferation of mirrors/repos/etc.
>>
>> Also, we're not staying on subversion - well, as far I know.
>
> At least not parallel to Mercurial.  Definitely.
>
> Georg

Well, I was worried I missed a meeting in the secret clubhouse.
___
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] Mercurial migration readiness

[Martin Geisler]

"Stephen J. Turnbull"  writes:

> anatoly techtonik writes:
>
>  > To be prepared for conflicts I review code with `svn log -vr
>  > base:head` before updating.  But with Mercurial I see two major
>  > problems with my workflow (which I am unlikely to change for the
>  > next few weeks due to heavy automation):
>  > 1. No shallow checkouts - that means that I have to copy 200Mb+ for
>  > every patch I have
>
> No, you don't.  You make links to 200MB+ (unless you're on Windows,
> where I don't know how this works).

Surprisingly, it works there too due to NTFS hardlinks :-)

> This is much cheaper than copying, though not as cheap as in git. I
> don't hesitate to make branches in Mercurial.

You can have branches inside your repository with Mercurial too, just
like in Git. The bookmarks extension is for that. With Mercurial 1.6,
you can push and pull bookmarks -- they are no longer local-only.

I may work more sequentially than most, but I do all my work on
Mercurial using a single clone.

>  > 3. There is no clear branch separation in my working copy. I don't
>  > know how to diff files in different branches without copying 200Mb+
>  > clone. I don't know how to diff my files with remote repository
>  > without pulling it.
>
> If you're at all serious about working with Mercurial, you don't do
> any operations except pull (and push, if you're a committer) against
> the remote.  You keep a local pristine mirror of the remote
> repository, which you update frequently, and all of your work revolves
> around that rather than around contact with upstream.
>
> This does mean that when upstream uses a repo-per-branch model you
> have to keep multiple mirrors.  On the other hand, you can work
> directly in branches that you work on only infrequently, and also use
> Mercurial queues to avoid making branches if you don't want to.

That is one option and I think "The Definitive Guide" advocates it.

However, you are free to mix the upstream clones into a single clone if
you want (with 'hg pull' from different upstream repositories), or you
can keep them separate.

If the upstream uses a single repository with multiple named brancehs,
then you can still maintain separate clones locally, say one per named
branch (with 'hg clone http://...#branch' style clones).

There is really no contraints on how you can setup your local
repositories.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/


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

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

[Steven D'Aprano]

Wow! I didn't expect anywhere near this amount of interest. Thanks to 
all who responded. One small comment follows:


On Sat, 3 Jul 2010 03:44:05 am Guido van Rossum wrote:
> On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan  
wrote:

> > Given the diverse range of uses Python is put to, moving things
> > from runtime to compile time can definitely have significant
> > unexpected consequences (hence why many of us would be hesitant to
> > consider an implementation that made such changes to be an actual
> > Python implementation).
>
> +1 on not changing this.
>
> For one, this will most likely break a large amount of 3rd party and
> stdlib software -- there are tons of statements like this that are
> practically unreachable or intentional.
>
> Second, I don't think it's going to make the kind of difference the
> OP is thinking of. 

As I said in my initial post, this was a hypothetical, not a serious 
suggestion for a change, so I'm not pushing for it. I'm not even sure I 
would vote for change -- somebody asked on #python whether 
implementations were free to reject semantically impossible code at 
compile-time, my first instinct was to say Yes, and then I thought 
about it a bit more and thought "maybe not" and decided to ask here. 
I'm glad I did, because I've learned a lot.

*If* such a change was made, I think it would have to be controlled by a 
command-line switch or environmental variable, like -O, and documented 
as potentially changing the behaviour of the program. But given how few 
accidental errors are likely to be caught by this, I doubt it would be 
of any real benefit.


Thanks to all who answered!



-- 
Steven D'Aprano
___
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] Mercurial migration readiness

[Martin v. Löwis]

> I don't know about "try" -- personally I don't see a difference for
> the release procedure, no matter where the source comes from.

I guess you haven't done a release yet, then :-)

Assuming you are going to use

https://svn.python.org/projects/sandbox/trunk/release/release.py

then you'll have to port that to Mercurial, first.

Or, you write your own release tool, as any serious release manager did
so far :-)

As for the Windows build, I don't know how to do "externals", yet.
In particular, I don't think it is a good idea to have all externals
in a single Mercurial clone: due to versioning, we have multiple copies
of them, which will take quite some space.

As a minor problem: I currently have a batch file head.bat, which
updates sysmodule.c after a switch to expand HeadURL correctly.
Not sure whether this will be needed on Mercurial, or whether the
build identification patch is able to learn about tags in the first
place.

Finally, I wonder how the documentation build process will continue to
integrate subversion. I guess you just need to have an svn binary around
when building the documentation.

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] Are you ready for Mercurial migration?

[Ben Finney]

anatoly techtonik  writes:

> Thanks for feedback. It appears that I overestimated the
> ubiquitousness of Google Wave. It already has some valuable feedback
> and I would really prefer to carry out all discussions there.

And yet it excludes anyone who doesn't want an account with a specific
organisation.

A barrier that is not present for discussions in this forum.

-- 
 \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” |
  `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it |
_o__)later?” —http://www.achewood.com/ |
Ben Finney

___
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] Mercurial migration readiness

[Martin v. Löwis]

Am 02.07.2010 15:09, schrieb Fred Drake:
> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
>> The two sets of repositories use different conversion tools and rules.
>> They have nothing in common (different changeset IDs, different
>> metadata, different branch/clone layout).
> 
> I'd love to see a more detailed description of this, including why
> someone new to Mercurial would choose one over the other.

I think someone new to Mercurial shouldn't choose either one.

Just sit back and wait for the real migration to happen.

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] Mercurial migration readiness

[Martin v. Löwis]

> Can somebody comment on how much ongoing effort is required to keep that
> mirror running?

As everybody else indicated: none (I believe).

FWIW, the bzr mirror wasn't that self-maintaining: the process started
to consume too much memory and got killed; the cron jobs broke, and so
on, so we finally switched it of (in favor of the Launchpad mirror that
also existed).

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] SVN <-> HG workflow to split Python Library by Module

[David Cournapeau]

On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon  wrote:
> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik  wrote:
>> I planned to publish this proposal when it is finally ready and tested
>> with an assumption that Subversion repository will be online and
>> up-to-date after Mercurial migration. But recent threads showed that
>> currently there is no tested mechanism to sync Subversion repository
>> back with Mercurial, so it will probably quickly outdate, and the
>> proposal won't have a chance to be evaluated. So now is better than
>> never.
>>
>> So, this is a way to split modules from monolithic Subversion
>> repository into several Mercurial mirrors - one mirror for each module
>> (or whatever directory structure you like). This will allow to
>> concentrate your work on only one module at a time ("distutils",
>> "CGIHTTPServer" etc.) without caring much about anything else.
>> Exceptionally useful for occasional external "contributors" like me,
>> and folks on Windows, who don't possess Visual Studio to compile
>> Python and are forced to use whatever version they have installed to
>> create and test patches.
>
> But modules do not live in an isolated world; they are dependent on
> changes made to other modules. Isolating them from other modules whose
> semantics change during development will lead to skew and improper
> patches.

I cannot comment on the original proposal, but this issue has known
solutions in git, in the form of submodules. I believe hg has
something similar with the forest extension

http://mercurial.selenic.com/wiki/ForestExtension

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] Are you ready for Mercurial migration?

[Martin v. Löwis]

Am 02.07.2010 17:08, schrieb Antoine Pitrou:
> On Fri, 2 Jul 2010 17:29:02 +0300
> anatoly techtonik  wrote:
>> To shed some light on the readiness of Python community for the switch
>> I've opened public Google Wave. Please add your opinion if you can and
>> send this link to other contributors you may know:
> 
> Am I the only one to think this should really stop?

You are certainly not alone. However, I've given up responding to
anatoly techtonik, knowing that it will be futile, and a waste of time.

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] SVN <-> HG workflow to split Python Library by Module

[Brett Cannon]

On Fri, Jul 2, 2010 at 17:17, David Cournapeau  wrote:
> On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon  wrote:
>> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik  wrote:
>>> I planned to publish this proposal when it is finally ready and tested
>>> with an assumption that Subversion repository will be online and
>>> up-to-date after Mercurial migration. But recent threads showed that
>>> currently there is no tested mechanism to sync Subversion repository
>>> back with Mercurial, so it will probably quickly outdate, and the
>>> proposal won't have a chance to be evaluated. So now is better than
>>> never.
>>>
>>> So, this is a way to split modules from monolithic Subversion
>>> repository into several Mercurial mirrors - one mirror for each module
>>> (or whatever directory structure you like). This will allow to
>>> concentrate your work on only one module at a time ("distutils",
>>> "CGIHTTPServer" etc.) without caring much about anything else.
>>> Exceptionally useful for occasional external "contributors" like me,
>>> and folks on Windows, who don't possess Visual Studio to compile
>>> Python and are forced to use whatever version they have installed to
>>> create and test patches.
>>
>> But modules do not live in an isolated world; they are dependent on
>> changes made to other modules. Isolating them from other modules whose
>> semantics change during development will lead to skew and improper
>> patches.
>
> I cannot comment on the original proposal, but this issue has known
> solutions in git, in the form of submodules. I believe hg has
> something similar with the forest extension
>
> http://mercurial.selenic.com/wiki/ForestExtension

Mercurial has subrepo support, but that doesn't justify the need to
have every module in its own repository so they can be checked out
individually.
___
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] Can Python implementations reject semantically invalid expressions?

[Greg Ewing]

Stefan Behnel wrote:


So, would it still be Python if it folded

1 + "1"

into

raise TypeError()

at compile time?


It would have to be

   raise TypeError("Exactly the message that would have been produced at run 
time")

That might be acceptable, but then you have to ask, is it really
worth performing this optimisation? The overhead of raising and
handling the exception is likely to completely swamp that of
executing the original code.

--
Greg
___
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] Can Python implementations reject semantically invalid expressions?

[Greg Ewing]

Craig Citro wrote:


Ok, I'm obviously being silly here, but sure you can:


dis.dis("raise TypeError()")


If producing different bytecode were considered a reason
against performing an optimisation, then no code optimisations
would be permissible at all!

--
Greg
___
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] SVN <-> HG workflow to split Python Library by Module

[David Cournapeau]

On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon  wrote:
> On Fri, Jul 2, 2010 at 17:17, David Cournapeau  wrote:
>> On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon  wrote:
>>> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik  wrote:
 I planned to publish this proposal when it is finally ready and tested
 with an assumption that Subversion repository will be online and
 up-to-date after Mercurial migration. But recent threads showed that
 currently there is no tested mechanism to sync Subversion repository
 back with Mercurial, so it will probably quickly outdate, and the
 proposal won't have a chance to be evaluated. So now is better than
 never.

 So, this is a way to split modules from monolithic Subversion
 repository into several Mercurial mirrors - one mirror for each module
 (or whatever directory structure you like). This will allow to
 concentrate your work on only one module at a time ("distutils",
 "CGIHTTPServer" etc.) without caring much about anything else.
 Exceptionally useful for occasional external "contributors" like me,
 and folks on Windows, who don't possess Visual Studio to compile
 Python and are forced to use whatever version they have installed to
 create and test patches.
>>>
>>> But modules do not live in an isolated world; they are dependent on
>>> changes made to other modules. Isolating them from other modules whose
>>> semantics change during development will lead to skew and improper
>>> patches.
>>
>> I cannot comment on the original proposal, but this issue has known
>> solutions in git, in the form of submodules. I believe hg has
>> something similar with the forest extension
>>
>> http://mercurial.selenic.com/wiki/ForestExtension
>
> Mercurial has subrepo support, but that doesn't justify the need to
> have every module in its own repository so they can be checked out
> individually.

It does not justify it, but it makes it possible to keep several
repositories in sync, and that you get a consistent state when cloning
the top repo. If there is a need to often move code from one repo to
the other, or if a change in one repo often cause a change in another
one, then certainly that's a sign that they should  be in the same
repo.

But for the windows issue, using subrepo so that when you clone python
repo, you get the exact same versions of C libraries as used for the
official msi (tk, tcl, openssl, bzip2, etc...), that would be very
useful. At least I would have prefered this to the current situation
when I need to build python myself on windows.

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] SVN <-> HG workflow to split Python Library by Module

[Steve Holden]

Jesse Noller wrote:
> On Fri, Jul 2, 2010 at 5:57 PM, Georg Brandl  wrote:
>> Am 02.07.2010 22:01, schrieb Jesse Noller:
>>
 I am exhausted.
>>> fwiw - there is a/are plan(s) to break out the stdlib from "core" once
>>> the transition is complete, to better allow re-use between the various
>>> interpreters. I do not think that "lots of small mirrors/repos" for
>>> each library is a net gain. Once the stdlib is broken out; the same
>>> thing you have proposed is achievable (within reason) without a
>>> proliferation of mirrors/repos/etc.
>>>
>>> Also, we're not staying on subversion - well, as far I know.
>> At least not parallel to Mercurial.  Definitely.
>>
>> Georg
> 
> Well, I was worried I missed a meeting in the secret clubhouse.

I've told you before about mentioning the club house on public mailing
lists. Remember, there IS NO PSU ...
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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] SVN <-> HG workflow to split Python Library by Module

[Steve Holden]

David Cournapeau wrote:
> On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon  wrote:
>> On Fri, Jul 2, 2010 at 17:17, David Cournapeau  wrote:
>>> On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon  wrote:
 On Fri, Jul 2, 2010 at 12:25, anatoly techtonik  
 wrote:
> I planned to publish this proposal when it is finally ready and tested
> with an assumption that Subversion repository will be online and
> up-to-date after Mercurial migration. But recent threads showed that
> currently there is no tested mechanism to sync Subversion repository
> back with Mercurial, so it will probably quickly outdate, and the
> proposal won't have a chance to be evaluated. So now is better than
> never.
>
> So, this is a way to split modules from monolithic Subversion
> repository into several Mercurial mirrors - one mirror for each module
> (or whatever directory structure you like). This will allow to
> concentrate your work on only one module at a time ("distutils",
> "CGIHTTPServer" etc.) without caring much about anything else.
> Exceptionally useful for occasional external "contributors" like me,
> and folks on Windows, who don't possess Visual Studio to compile
> Python and are forced to use whatever version they have installed to
> create and test patches.
 But modules do not live in an isolated world; they are dependent on
 changes made to other modules. Isolating them from other modules whose
 semantics change during development will lead to skew and improper
 patches.
>>> I cannot comment on the original proposal, but this issue has known
>>> solutions in git, in the form of submodules. I believe hg has
>>> something similar with the forest extension
>>>
>>> http://mercurial.selenic.com/wiki/ForestExtension
>> Mercurial has subrepo support, but that doesn't justify the need to
>> have every module in its own repository so they can be checked out
>> individually.
> 
> It does not justify it, but it makes it possible to keep several
> repositories in sync, and that you get a consistent state when cloning
> the top repo. If there is a need to often move code from one repo to
> the other, or if a change in one repo often cause a change in another
> one, then certainly that's a sign that they should  be in the same
> repo.
> 
> But for the windows issue, using subrepo so that when you clone python
> repo, you get the exact same versions of C libraries as used for the
> official msi (tk, tcl, openssl, bzip2, etc...), that would be very
> useful. At least I would have prefered this to the current situation
> when I need to build python myself on windows.
> 
It does sound like it would be helpful, though I guess we would have to
check each project to ensure we had a license to redistribute under some
terms or other ...

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
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

[Python-Dev] blocking 2.7

[Benjamin Peterson]

This is just a note that we have one bug blocking 2.7 final at the
moment: http://bugs.python.org/issue9144

-- 
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] Can Python implementations reject semantically invalid expressions?

[Greg Ewing]

Steven D'Aprano wrote:
if the keyhole optimizer raised SyntaxError (or 
some other exception) on seeing this:


def f():
return 1 + "1"


That might break code that was deliberately trying to raise
an exception. Sometimes you see things like

  try:
1/0
  except Exception, e:
...

Usually this kind of thing is only done in test code or
illustrative snippets, but even so, it should work as
expected.

--
Greg
___
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] blocking 2.7

[Nick Coghlan]

On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson  wrote:
> This is just a note that we have one bug blocking 2.7 final at the
> moment: http://bugs.python.org/issue9144

I added Jesse to the nosy list for that as well.

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] Can Python implementations reject semantically invalid expressions?

[Steven D'Aprano]

On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:
> Stefan Behnel wrote:
> > So, would it still be Python if it folded
> >
> >     1 + "1"
> >
> > into
> >
> >     raise TypeError()
> >
> > at compile time?
>
> It would have to be
>
>     raise TypeError("Exactly the message that would have been
> produced at run time")


Python doesn't make any guarantees about the message that exceptions 
display, so I don't think you need to match the message, just the 
exception. Anyone testing for specific exception messages is living in 
a state of sin and shouldn't complain when their code stops working. An 
implementation might choose to raise TypeError('is this the right place 
for an argument?') on alternate Tuesdays, and it would still meet the 
promises made by the language.


-- 
Steven D'Aprano
___
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] Can Python implementations reject semantically invalid expressions?

[Greg Ewing]

Craig Citro wrote:


However, in this particular case, here's a question: *why* would
someone write "return 1 + '1'"?


They might not intend to execute the code at all -- e.g.
they may want to pass the compiled code to dis() to find
out what bytecode gets generated. Having it refuse to
compile would be annoying in that case.

--
Greg
___
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] Mercurial migration readiness

[Eli Bendersky]

> > > This information really belongs in www.python.org/dev/ rather than
> > > only in the mailing list.
> > >
> > +1
> >
> > As does a recent essay by Eli Bendersky, IMO. I believe it could lower
> > the barriers for entry into the "non-committer" class of developer. This
> > should make it easier for people to adapt Python to their own purposes
> > whether or not they want to contribute to the open source code base, but
> > also encourage people to investigate the compiler's innards.
>
> With the moratorium on language constructs and builtins (not only in
> letter until 3.3, but more generally in spirit), I don't think we should
> encourage it at all, for such contributions would surely be rejected.
>
> Rather than fancy syntax propositions or wild semantic
> changes/enhancements (such as have often been proposed on
> python-ideas), what we need is humbler but more useful work on stdlib
> bugs and improvements, as well as documentation and tutorials.
>
> (what's more, those two kinds of contributions are likely to attract
> two different kinds of people, which means that people whose syntax
> patches get refused won't necessarily start contributing stdlib or
> documentation patches...)
>
> Regards
>
> Antoine.
>
>
Antoine,

I wrote that article, and I agree with everything you say here. I just don't
want my intentions to be understood incorrectly. Many readers stopped
reading after the title and jumped to conclusions which simply aren't true
(as some of the comments on the blog and Reddit demonstrate). Just a couple
of quotes from the article itself to show that breaking the moratorium (with
which I wholeheartedly agree) is far from my intentions:

-
This article is an attempt to better understand how the front-end of Python
works. Just reading documentation and source code may be a bit boring, so
I’m taking a hands-on approach here: I’m going to add an until statement to
Python.
[...]
This article doesn’t attempt to suggest the addition of an until statement
to Python. Although I think such a statement would make some code clearer,
and this article displays how easy it is to add, I completely respect
Python’s philosophy of minimalism. All I’m trying to do here, really, is
gain some insight into the inner workings of Python.
-

Kind regards,
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

[Python-Dev] More detailed build instructions for Windows

[Reid Kleckner]

Hey folks,

I'm trying to test out a patch to add a timeout in subprocess.py on
Windows, so I need to build Python with Visual Studio.  The docs say
the files in PCBuild/ work with VC 9 and newer.  I downloaded Visual
C++ 2010 Express, and it needs to convert the .vcproj files into
.vcxproj files, but it fails.

I can't figure out where to get VC 9, all I see is 2008 and 2010.  Can
someone with experience share the best practices for building Python
on Windows?  In particular, what is the most recent compiler known to
work and where can I download it?

Thanks,
Reid
___
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] Can Python implementations reject semantically invalid expressions?

[Stefan Behnel]

Steven D'Aprano, 03.07.2010 06:35:

On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:

Stefan Behnel wrote:

So, would it still be Python if it folded

 1 + "1"

into

 raise TypeError()

at compile time?


It would have to be

 raise TypeError("Exactly the message that would have been
produced at run time")


Python doesn't make any guarantees about the message that exceptions
display, so I don't think you need to match the message, just the
exception. Anyone testing for specific exception messages is living in
a state of sin and shouldn't complain when their code stops working.


Yep, the Cython project keeps running into this all over the place. When we 
reimplement CPython functionality for performance reasons, we make sure we 
match the behaviour exactly, which usually means that we try to match the 
exceptions and their messages as well. Since we use doctests for our test 
suite, this means that we need to special case some Python versions in the 
test suite to make sure we test our code as good as possible without 
letting the tests break across CPython versions. This can be really tricky 
at times.


The general trend seems to be that modified exception messages become more 
exact and telling over time, so we tend to follow Python 3.x in our own 
choice of error messages.


Stefan

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

Re: [Python-Dev] More detailed build instructions for Windows

[David Cournapeau]

On Sat, Jul 3, 2010 at 2:26 PM, Reid Kleckner  wrote:
> Hey folks,
>
> I'm trying to test out a patch to add a timeout in subprocess.py on
> Windows, so I need to build Python with Visual Studio.  The docs say
> the files in PCBuild/ work with VC 9 and newer.  I downloaded Visual
> C++ 2010 Express, and it needs to convert the .vcproj files into
> .vcxproj files, but it fails.
>
> I can't figure out where to get VC 9, all I see is 2008 and 2010.

VS 2008 == VC 9 == MSVC 15

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