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

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

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

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

[Python-Dev] More detailed build instructions for Windows

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,

Re: [Python-Dev] Mercurial migration readiness

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

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

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 wo

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

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

Re: [Python-Dev] blocking 2.7

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

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

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: ... Usua

[Python-Dev] blocking 2.7

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://ma

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

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 propos

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

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

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

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 test

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

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

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

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

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

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

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

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 yo

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

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 r

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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 t

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

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 organ

Re: [Python-Dev] Mercurial migration readiness

> 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

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

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

Re: [Python-Dev] Mercurial migration readiness

"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

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

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 th

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

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

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

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 m

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

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 ar

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

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

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

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

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

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 i

Re: [Python-Dev] Mercurial migration readiness

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

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

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 involv

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

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

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

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

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

> 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

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

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 c

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

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 p

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

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

Re: [Python-Dev] Mercurial migration readiness

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

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

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

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

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 conversi

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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

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

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

Re: [Python-Dev] Mercurial migration readiness

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 d

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

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

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

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

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

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

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

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 Go

[Python-Dev] Summary of Python tracker Issues

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 Ave

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

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 Mercu

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

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 -

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

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

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

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 a

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

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 mi

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

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

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

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

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

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

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

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

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

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 partici

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

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

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

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

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

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 proce

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

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

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

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

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

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

Re: [Python-Dev] Mercurial migration readiness

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 s

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

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 re

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

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 p

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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 suggest

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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 swit

Re: [Python-Dev] Mercurial migration readiness

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

Re: [Python-Dev] Mercurial migration readiness

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

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

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

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

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

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

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 stri

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

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 >

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

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

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

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 P

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

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 t

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

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

Re: [Python-Dev] Mercurial migration readiness

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 ma

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

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

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

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

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

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 unde

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

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

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

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