Glyph Lefkowitz, 02.07.2010 06:43:
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an
On Fri, Jul 2, 2010 at 12:31 AM, Stefan Behnel stefan...@behnel.de wrote:
Glyph Lefkowitz, 02.07.2010 06:43:
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that
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 1158293
6 IMPORT_STAR
7 SETUP_EXCEPT25968 (to 25978)
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
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com 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)
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller jnol...@gmail.com 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.
On Fri, Jul 2, 2010 at 8:22 AM, Mark Dickinson dicki...@gmail.com wrote:
On Fri, Jul 2, 2010 at 7:55 AM, Craig Citro craigci...@gmail.com wrote:
dis.dis(raise TypeError())
0 114 26977
3 115 8293
6 IMPORT_STAR
7 SETUP_EXCEPT 25968
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull step...@xemacs.org 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
On 02/07/2010 08:25, Dirkjan Ochtman wrote:
On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbullstep...@xemacs.org 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
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 techto...@gmail.com
mailto:techto...@gmail.com wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull
it and I
Am 02.07.2010 09:27, schrieb anatoly techtonik:
On Thu, Jul 1, 2010 at 6:16 PM, Jesse Noller jnol...@gmail.com 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
On Fri, Jul 2, 2010 at 1:20 AM, Martin v. Löwis mar...@v.loewis.de 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
Am 02.07.2010 01:05, schrieb Antoine Pitrou:
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon br...@python.org 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
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 1158293
6
On Fri, Jul 2, 2010 at 12:25 PM, Steven D'Aprano st...@pearwood.info 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
On Fri, Jul 2, 2010 at 4:55 PM, Craig Citro craigci...@gmail.com 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
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 jnol...@gmail.com 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
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
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo mer...@netwok.org 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
On Fri, 2 Jul 2010 15:22:44 +0300
anatoly techtonik techto...@gmail.com wrote:
On Fri, Jul 2, 2010 at 3:02 PM, Éric Araujo mer...@netwok.org 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
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net 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
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
On Fri, 2 Jul 2010 09:09:48 -0400
Fred Drake fdr...@acm.org wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs, different
metadata,
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl g.bra...@gmx.net 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
Am 02.07.2010 15:48, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 11:33 AM, Georg Brandl g.bra...@gmx.net 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
On Fri, Jul 2, 2010 at 15:21, Antoine Pitrou solip...@pitrou.net 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.
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@gmx.net 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
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.
On Fri, Jul 2, 2010 at 16:17, anatoly techtonik techto...@gmail.com 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.
On Fri, Jul 2, 2010 at 10:17 AM, anatoly techtonik techto...@gmail.com wrote:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@gmx.net wrote:
What is the problem with realtime synchronization and working with
already up to date Mercurial mirror of central SVN repository?
The specifics
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
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
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
On Fri, 2 Jul 2010 17:29:02 +0300
anatoly techtonik techto...@gmail.com 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
-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 g.bra...@gmx.net wrote:
So, if I understand correctly - there are no Mercurial mirrors for
testing at the moment,
There are
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@gmx.net 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
É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
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
On Fri, Jul 2, 2010 at 10:16, anatoly techtonik techto...@gmail.com 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
É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
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
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
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
On Fri, Jul 2, 2010 at 6:28 PM, Brian Curtin brian.cur...@gmail.com 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
On Fri, Jul 2, 2010 at 3:44 PM, Craig Citro craigci...@gmail.com 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
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
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
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net 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
On Sat, Jul 3, 2010 at 2:51 AM, Craig Citro craigci...@gmail.com 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
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*.
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs,
Georg Brandl wrote:
Am 02.07.2010 16:17, schrieb anatoly techtonik:
On Fri, Jul 2, 2010 at 4:53 PM, Georg Brandl g.bra...@gmx.net 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
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
On Fri, Jul 2, 2010 at 1:12 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different
anatoly techtonik wrote:
On Fri, Jul 2, 2010 at 6:28 PM, Brian Curtin brian.cur...@gmail.com 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
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
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com 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
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
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com 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
2010/7/2 Guido van Rossum gu...@python.org
On Fri, Jul 2, 2010 at 10:28 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Jul 3, 2010 at 3:13 AM, Craig Citro craigci...@gmail.com
wrote:
1/0 is much faster to type than raise SomeError and serves the same
purpose sometimes for debugging
On Fri, Jul 2, 2010 at 08:49, anatoly techtonik techto...@gmail.com 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
Antoine Pitrou wrote:
On Fri, 02 Jul 2010 12:55:56 -0400
Steve Holden st...@holdenweb.com wrote:
Fred Drake wrote:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common
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
On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik techto...@gmail.com 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
On Fri, Jul 2, 2010 at 3:25 PM, anatoly techtonik techto...@gmail.com 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
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
On Fri, Jul 2, 2010 at 12:25, anatoly techtonik techto...@gmail.com 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
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
On Fri, Jul 2, 2010 at 5:57 PM, Georg Brandl g.bra...@gmx.net 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
Stephen J. Turnbull step...@xemacs.org 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
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 ncogh...@gmail.com
wrote:
Given the diverse range of uses Python is put
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
anatoly techtonik techto...@gmail.com 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
Am 02.07.2010 15:09, schrieb Fred Drake:
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net 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).
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
On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon br...@python.org wrote:
On Fri, Jul 2, 2010 at 12:25, anatoly techtonik techto...@gmail.com 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
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
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
On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon br...@python.org wrote:
On Fri, Jul 2, 2010 at 17:17, David Cournapeau courn...@gmail.com wrote:
On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon br...@python.org wrote:
On Fri, Jul 2, 2010 at 12:25, anatoly techtonik techto...@gmail.com wrote:
I
Jesse Noller wrote:
On Fri, Jul 2, 2010 at 5:57 PM, Georg Brandl g.bra...@gmx.net 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
David Cournapeau wrote:
On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon br...@python.org wrote:
On Fri, Jul 2, 2010 at 17:17, David Cournapeau courn...@gmail.com wrote:
On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon br...@python.org wrote:
On Fri, Jul 2, 2010 at 12:25, anatoly techtonik
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:
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:
...
On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson benja...@python.org 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
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)
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
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
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,
88 matches
Mail list logo
