Great idea! Sounds like a PEP (informational, probably) would be good idea.
On Tue, Mar 18, 2008 at 4:59 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I don't think this is bike-shedding.
>
> The debate about "AMD64" vs. "amd64" vs. "x86_64" reminded me that
> I've been bit more and more frequen
On Wed, Mar 19, 2008 at 10:27 PM, David Wolever <[EMAIL PROTECTED]> wrote:
> On 19-Mar-08, at 6:44 PM, Collin Winter wrote:
> > You can pass -p to refactor.py to fix this on a per-run basis. See
> > r58002 (and the revisions it mentions) for a failed attempt to do this
> > automatically.
>
> So
Sounds good!
On Wed, Mar 19, 2008 at 10:04 PM, David Wolever <[EMAIL PROTECTED]> wrote:
> Would anyone be averse to changing pytree.Node's __repr__ so it
> includes the name of the name of the symbol the node represents?
>
> The only downside is that it makes the __reprs__ longer... But I
> thi
On 19-Mar-08, at 6:44 PM, Collin Winter wrote:
> You can pass -p to refactor.py to fix this on a per-run basis. See
> r58002 (and the revisions it mentions) for a failed attempt to do this
> automatically.
So, correct me if I'm wrong, but the relevant code is this:
-try:
-
I was using the human interface at python.org/pypi. There are two
prominent links at the top of the page: "Browse the tree of packages"
and "Submit package information" followed by the 30 most recently
changed packages. What I was looking for was the page for a specific
package. The "Browse the tre
Would anyone be averse to changing pytree.Node's __repr__ so it
includes the name of the name of the symbol the node represents?
The only downside is that it makes the __reprs__ longer... But I
think its worth the length:
Node(313:simple_stmt, [Node(298:import_name, [Leaf(1, 'import'), Node
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [a long message]
>
> I'm back at Google and *really* busy for another week or so, so I'll
> have to postpone the rest of this discussion for a whil
Martin v. Löwis wrote:
>> specific code in PyPI. Are developers for Python 3.x encouraged in
>> 3.x guidelines to release 'fat' distributions that combine 2.x and 3.x
>> usable versions?
>
> Passive voice is misleading here: encouraged by whom?
"... encouraged in __3.x guidelines__ to ...": I
On Mar 19, 2008, at 3:23 PM, Guido van Rossum wrote:
> If other people want to chime in please do so; if this is just a
> dialog between Phillip and me I might incorrectly assume
> that nobody besides Phillip really cares.
I really care. I've used setuptools, easy_install, eggs, and
pkg_resour
Unfortunately, I don't have ssh access from my hotel room. This means
I won't be able to help much until I get home.
On Wed, Mar 19, 2008 at 7:26 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> Quick update on the status of the trunk buildbots:
>
> Failing:
> [x86 gentoo trunk (Neal Norwitz)]
>
Nice and simple, thanks, Martin!
Works OK after I upgraded to MinGW 5.1.3 (5.0.0 is what I had, and the
gcc build didn't work there with that).
I think I've got it!
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Hmmm, sorry if I'm missing something obvious, but, if the occasional
background computations are sufficiently heavy -- why not fork, do
said computations in the child thread, and return the results via any
of the various available IPC approaches? I've recently (at Pycon,
mostly) been playing devil
> I've set up a Parallels virtual machine on my Mac, and have succeeded
> in getting Windows XP running in it! And I've installed MinGW, as
> well. Now I'd like to learn how to build the SSL module from source
> on Windows for Python 2.5.2. Is there any documentation on the
> process of building
Leif Walsh wrote:
> On Wed, Mar 19, 2008 at 7:05 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
>> > This strikes me as a gratuitous API change of the kind Guido was
>> > warning about in his recent post: "Don't change your APIs incompatibly
>> > when porting to Py3k"
>>
>> This seems compelling t
> Yes, I am assuming that existing projects would at some point introduce a 3.x
> version and maybe continue a 2.x version as separate distros, similar to
> Python itself. Then the large number of existing unqualified dependencies
> on,
> say SQLObject, would pull in the higher 3.x version and
>> You seem to be implying that some projects may release separate
>> source distributions. I cannot imagine why somebody would want to
>> do that.
>
> That's odd. I can't imagine why anybody would *not* want to do that.
> Given the number of issues 2to3 can't fix (because it would be too
> dange
> While not quite to the same scale as the 2 to 3 transition, this problem
> seems like one that would generally already exist. If one writes code
> that uses newer 2.4/2.5 features (say decorators for example,) it won't
> build/run on 2.3 or earlier installs. How have people been handling
>
> I don't understand PyPI all that well; it seems poor design that the
> browsing via keywords is emphasized but there is no easy way to
> *search* for a keyword (the list of all packages is not emphasized
> enough on the main page -- it occurs in the side bar but not in the
> main text).
I don't
I'd recommend cd'ing to your trunk root directory and running
Tool\buildbot\build.bat from there -- it'll automatically check out all the
dependencies and build via command line with vcbuild (building via Visual
Studio usually always Does The Right Thing, command line builds often take a
bit mo
Then put the picture on your screen and SEND ME A SCREENSHOT!
regards
Steve
Neal Norwitz wrote:
> Great work Trent! You'll need to take a picture of Martin buying you
> the beer once you get the rest green. :-)
>
> n
>
> On Wed, Mar 19, 2008 at 5:57 PM, Trent Nelson <[EMAIL PROTECTED]> wrote
On Wed, Mar 19, 2008 at 7:05 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> > This strikes me as a gratuitous API change of the kind Guido was
> > warning about in his recent post: "Don't change your APIs incompatibly
> > when porting to Py3k"
>
> This seems compelling to me. And as Glyph mentio
Trent Nelson wrote:
> Quick update on the status of the trunk buildbots:
>
> [x86 XP trunk (Joseph Armbruster)]
> This box didn't survive the recent build changes, but I can't figure out why,
> none of the other Windows boxes encounter this error:
> The following error has occurred during XML par
> The Python sandbox has a setuptools directory. Is this the canonical
> location for the code?
Yes, it is.
> If so, then anybody who has Python commit
> privileges can commit to it and help further develop setuptools.
They can, but they shouldn't. Nothing should be committed there
without
> Having recently sunk a lot of time into the Windows build process, I'd
> recommend going with Visual C++ Express 2008 rather than MinGW, as this is
> the official compiler for 2.6/3.0. (You can download a free copy.)
Thanks for the advice, but it's sort of Greek to me. Is there a
step-by-ste
Quick update on the status of the trunk buildbots:
Failing:
[x86 gentoo trunk (Neal Norwitz)]
This has been failing at the same point for the past couple of days now:
test_sqlite
command timed out: 1800 seconds without output, killing pid 15168
process killed by signal 9
program finished with exit
Having recently sunk a lot of time into the Windows build process, I'd
recommend going with Visual C++ Express 2008 rather than MinGW, as this is the
official compiler for 2.6/3.0. (You can download a free copy.)
FWIW, I've probably been working on the Windows build side of things on and off
f
On Wed, Mar 19, 2008 at 2:15 PM, <[EMAIL PROTECTED]> wrote:
>
> On 02:21 pm, [EMAIL PROTECTED] wrote:
> >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> >>with me.
> >
> >This strikes me as a gratuitous API change of the kind Guido was
> >warning about in his recent
I've set up a Parallels virtual machine on my Mac, and have succeeded
in getting Windows XP running in it! And I've installed MinGW, as
well. Now I'd like to learn how to build the SSL module from source
on Windows for Python 2.5.2. Is there any documentation on the
process of building an extens
* Neal Norwitz <[EMAIL PROTECTED]> [2008-03-18 18:54:47 -0500]:
> First, you should measure the current speed difference. Something like:
>
> $ ./python.exe -m timeit -s 'd = {1: None}' 'd[1]'
> 100 loops, best of 3: 0.793 usec per loop
> $ ./python.exe -m timeit -s 'd = {"1": None}' 'd["1"]
Great work Trent! You'll need to take a picture of Martin buying you
the beer once you get the rest green. :-)
n
On Wed, Mar 19, 2008 at 5:57 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> We've just experienced our first 2.6 green x64 Windows builds on the build
> slaves! Well, almost green.
Dear sprinters!
I've a batch of pending patches I like to get into Python before the
next alphas are send out. The math, epoll/kqueue and shell folder
patches just need a review. The memory management patches are more
complex. Please refer to the thread "int/float freelists vs pymalloc", too.
We've just experienced our first 2.6 green x64 Windows builds on the build
slaves! Well, almost green. Thomas's 'amd64 XP trunk' ran out of disk:
304 tests OK.
1 test failed:
test_largefile
==
ERROR: test_seek (test.test_la
Jeff Rush wrote:
> Perhaps it is time for a parallel rewrite,
> so that those setup.py who import distutils get the old behavior, and those
> who import distutils2 get the new,
That sounds good to me. If anyone wants to have a go
at this, I have some ideas on how to structure it
that I'd be happ
At 05:15 PM 3/19/2008 -0500, Jeff Rush wrote:
>Phillip J. Eby wrote:
> > At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
> >> Are you open to giving certain others patch view/commit privileges to
> >> setuptools?
> >
> > Jim Fulton has such already. I'm open to extending that to others who
> > have
On 19/03/2008, Michael Urman <[EMAIL PROTECTED]> wrote:
> > OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> > with me.
>
>
> This strikes me as a gratuitous API change of the kind Guido was
> warning about in his recent post: "Don't change your APIs incompatibly
> when po
Martin v. Löwis wrote:
>
> I don't see the need to for PyPI. For packages (or "distributions",
> to avoid confusion with Python packages), I see two options:
>
> a) provide a single release that supports both 2.x and 3.x.
> b) switch to Python 3 at some point (i.e. burn your bridges).
>
> You se
On Wed, Mar 19, 2008 at 5:02 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > This gem from unittest.py is pretty much the opposite of "one obvious
> way":
> >
> > # Synonyms for assertion method
On Wed, Mar 19, 2008 at 10:12 AM, Michael Urman <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 19, 2008 at 10:44 AM, Stephen J. Turnbull
> <[EMAIL PROTECTED]> wrote:
> > So we should add this to 2to3, no? They're going to run that anyway.
>
> If 2to3 can handle this, that removes the larger half of
On Wed, Mar 19, 2008 at 12:04 PM, David Wolever <[EMAIL PROTECTED]> wrote:
> At the moment, fix_print.py does the Right Thing when it finds ``from
> __future__ import print_function``... But the 2to3 parser gets upset
> when print() is passed kwargs:
> $ cat x.py
> from __future__ import print_
Jonathan Lange wrote:
> On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> This gem from unittest.py is pretty much the opposite of "one obvious way":
>>
>> # Synonyms for assertion methods
>>
>>
> [snip]
>
>> Could these be removed for 3k?
Phillip J. Eby wrote:
> At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
>> Are you open to giving certain others patch view/commit privileges to
>> setuptools?
>
> Jim Fulton has such already. I'm open to extending that to others who
> have a good grasp of the subtleties involved.
>
> Truthfully
On Wed, Mar 19, 2008 at 6:24 PM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This gem from unittest.py is pretty much the opposite of "one obvious way":
>
> # Synonyms for assertion methods
>
[snip]
>
> Could these be removed for 3k?
>
I agree with others who say that we shouldn't
On 08:34 pm, [EMAIL PROTECTED] wrote:
Martin v. L�wis wrote:
You seem to be implying that some projects may release separate
source distributions. I cannot imagine why somebody would want
to do that.
That's odd. I can't imagine why anybody would *not* want to do that.
Python 2 is going to
On Wed, Mar 19, 2008 at 12:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
[a long message]
I'm back at Google and *really* busy for another week or so, so I'll
have to postpone the rest of this discussion for a while. If other
people want to chime in please do so; if this is just a dialog betwee
On 02:21 pm, [EMAIL PROTECTED] wrote:
>>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
>>with me.
>
>This strikes me as a gratuitous API change of the kind Guido was
>warning about in his recent post: "Don't change your APIs incompatibly
>when porting to Py3k"
I agree empha
On Wed, Mar 19, 2008 at 11:01 AM, David Wolever <[EMAIL PROTECTED]>
wrote:
> At the moment, fixers are run in alphabetical order -- but this poses
> a problem, because some depend on others (for example, fix_print will
> need to be run _before_ fix_future, because fix_print looks for the
> 'from _
Martin v. Löwis wrote:
> I don't see the need to for PyPI. For packages (or "distributions",
> to avoid confusion with Python packages), I see two options:
>
> a) provide a single release that supports both 2.x and 3.x.
> The precise strategy to do so might vary. If one is going
> for a si
Martin v. Löwis wrote:
1. What is the plan for PyPI when Python 3.0 comes out and
dependencies start getting satisfied from distribution
across the great divide, e.g. a 3.0-specific package
pulls from PyPI a 2.x-specific package to meet some
need? Are there plans to fork PyPI, ap
At 10:48 AM 3/19/2008 -0700, Guido van Rossum wrote:
>I don't understand PyPI all that well; it seems poor design that the
>browsing via keywords is emphasized but there is no easy way to
>*search* for a keyword (the list of all packages is not emphasized
>enough on the main page -- it occurs in th
On 3/19/08, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> > I think (repeatedly) testing an app through IDLE is a reasonable use case.
> [other threads may still have references to loggers or handlers]
> > Would it be reasonable for shutdown to remove logging from
> > sys.modules, so that a rerun ha
Greg Ewing wrote:
> Neal Norwitz wrote:
>> Part of this is done, but very differently in that all strings used in
>> code objects are interned (stored in a dictionary
>
> And since two interned strings can be compared
> by pointer identity, I don't see how this differs
> significantly from the "un
On Wed, Mar 19, 2008 at 11:34 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> > > 4. The standard Python library includes a tool to find and read
> > > resources (o
At the moment, fix_print.py does the Right Thing when it finds ``from
__future__ import print_function``... But the 2to3 parser gets upset
when print() is passed kwargs:
$ cat x.py
from __future__ import print_function
print("Hello, world!", end=' ')
$ 2to3 x.py
...
RefactoringTool: Can't parse
Phillip J. Eby wrote:
At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
I'd be willing to help out, and keep a carefully balanced hand in
what is accepted.
I'm not sure exactly how to go about such a handoff though. My guess
is that we need a bug/patch tracker, and a few people to rev
On 19-Mar-08, at 2:18 PM, Benjamin Peterson wrote:
So, any better suggestions?
I would create a list of fixers that need to go first in
refactor.py and run those in order. If you wanted to get complex,
you could add a requires member to fixes, but that is probably
overkill.
Ok, so I was dig
On 19/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> > 4. The standard Python library includes a tool to find and read
> > resources (other than Python modules) that came bundled in a Python
> > package.
>
> I think
On Wed, Mar 19, 2008 at 1:01 PM, David Wolever <[EMAIL PROTECTED]>
wrote:
> At the moment, fixers are run in alphabetical order -- but this poses
> a problem, because some depend on others (for example, fix_print will
> need to be run _before_ fix_future, because fix_print looks for the
> 'from __
At the moment, fixers are run in alphabetical order -- but this poses
a problem, because some depend on others (for example, fix_print will
need to be run _before_ fix_future, because fix_print looks for the
'from __future__ import ...' statement.
I'm tempted to simply change fix_future to f
On Wed, Mar 19, 2008 at 11:25 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>
>
> > So you want responsiveness when idle but throughput when busy?
>
> Exactly ;)
>
>
> > Are those calculations primarily python code, or does a C library do
> > the grunt work? If it'
On Tue, Mar 18, 2008 at 3:36 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote:
> >Only very few people would care about writing a setup
> >script that works with this bootstrap module; basically only package
> >manager implementers.
>
> That's
Phillip J. Eby writes:
> >7. Many wanted to ability to install files anywhere in the install tree and
> > not just under the Python package. Under distutils this was possible
> > but
> > it was removed in setuptools for security reasons.
>
> It wasn't security, it was manageability. Egg
Adam Olsen gmail.com> writes:
> So you want responsiveness when idle but throughput when busy?
Exactly ;)
> Are those calculations primarily python code, or does a C library do
> the grunt work? If it's a C library you shouldn't be affected by
> safethread's increased overhead.
>
It's Python
On Mon, Mar 17, 2008 at 2:19 PM, zooko <[EMAIL PROTECTED]> wrote:
> 4. The standard Python library includes a tool to find and read
> resources (other than Python modules) that came bundled in a Python
> package.
>
> Consider, for example, this snippets of code in Nevow:
>
> http://divmod.org
Jeff Rush writes:
> I was in a Packaging BoF yesterday and, although not very relevant to the
> packager bootstrap thread, Guido has asked me to post some of the concerns.
We did address many topics on both days, I added the following topics
which were addressed on the Friday BoF only, see
http:/
On Wed, Mar 19, 2008 at 10:44 AM, Stephen J. Turnbull
<[EMAIL PROTECTED]> wrote:
> So we should add this to 2to3, no? They're going to run that anyway.
If 2to3 can handle this, that removes the larger half of my objection.
I was under the impression that this kind of semantic inferencing was
bey
On Wed, Mar 19, 2008 at 10:42 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
>
> On Mar 19, 2008 05:24 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Mar 19, 2008 at 10:09 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> > > Adam Olsen gmail.com> writes:
> > >
> > > > Can you try with a call
Adam Olsen gmail.com> writes:
>
> On Wed, Mar 19, 2008 at 10:09 AM, Stefan Ring visotech.at> wrote:
> > Adam Olsen gmail.com> writes:
> >
> > > Can you try with a call to sched_yield(), rather than nanosleep()? It
> > > should have the same benefit but without as much performance hit.
> >
Gabriel Grant wrote:
> Hi all,
>
> This gem from unittest.py is pretty much the opposite of "one obvious way":
>
> # Synonyms for assertion methods
>
> assertEqual = assertEquals = failUnlessEqual
>
> assertNotEqual = assertNotEquals = failIfEqual
>
> assertAlmostEqual = assertAlmos
On Wed, Mar 19, 2008 at 10:09 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>
> > Can you try with a call to sched_yield(), rather than nanosleep()? It
> > should have the same benefit but without as much performance hit.
> >
> > If it works, but is still too much
2008/3/19, Barry Warsaw <[EMAIL PROTECTED]>:
> > +1 to assert* from me. the fail* variants always feel like
> > double-negatives. I also always use assertTrue instead of assert_. But
> > I don't care enough to argue about it. :)
+1 to the plain affirmative propositions (assert*) instead of the
Adam Olsen gmail.com> writes:
> Can you try with a call to sched_yield(), rather than nanosleep()? It
> should have the same benefit but without as much performance hit.
>
> If it works, but is still too much hit, try tuning the checkinterval
> to see if you can find an acceptable throughput/re
On Tue, Mar 18, 2008 at 1:29 AM, Stefan Ring <[EMAIL PROTECTED]> wrote:
> The company I work for has over the last couple of years created an
> application server for use in most of our customer projects. It embeds Python
> and most project code is written in Python by now. It is quite
> resourc
Michael Urman writes:
> Yes it removes redundancy, but it really doesn't change the cognitive
> load (at least for native speakers).
Actually, OONTDI is important to me, cognitively. Multiple names
implies the possibility of multiple semantics, often unintentionally.
Here that can't be the cas
At 03:57 AM 3/19/2008 -0500, Jeff Rush wrote:
>Are you open to giving certain others patch view/commit privileges
>to setuptools?
Jim Fulton has such already. I'm open to extending that to others
who have a good grasp of the subtleties involved.
Truthfully, if we can just get 0.6 put to bed, I
Martin v. Löwis wrote:
>> That's odd. In theory, having msvcr90.dll in C:\Python26 should be
>> sufficient, as once python.exe is loaded, its directory is added to
>> the DLL search path. Maybe it's something to do with the "side by side
>> manifest installation" stuff (or whatever it's called).
>
> OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
> with me.
This strikes me as a gratuitous API change of the kind Guido was
warning about in his recent post: "Don't change your APIs incompatibly
when porting to Py3k"
Yes it removes redundancy, but it really doesn't change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 19, 2008, at 3:57 AM, Jeff Rush wrote:
>
> I and others appreciate your call for more patches on various
> topics. However
> a long delay in applying them will discourage contribution. Are you
> open to
> giving certain others patch view/c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 19, 2008, at 3:20 AM, Jeffrey Yasskin wrote:
> +1 to assert* from me. the fail* variants always feel like
> double-negatives. I also always use assertTrue instead of assert_. But
> I don't care enough to argue about it. :)
I'm in the camp that
> 1. What is the plan for PyPI when Python 3.0 comes out and
> dependencies start getting satisfied from distribution
> across the great divide, e.g. a 3.0-specific package
> pulls from PyPI a 2.x-specific package to meet some
> need? Are there plans to fork PyPI, apply special
>
On Wed, Mar 19, 2008 at 6:51 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> This flag is exposed to python code as sys.flags.py3k_warning
>
> So the hack added to some of the test code that I saw go by on
> python-checkins isn't needed :)
Somebody can remove TODO in Lib/test/test_py3kwarn.py.
>
>
Nick Coghlan wrote:
> eric.smith wrote:
>> [EMAIL PROTECTED]
>> +def stdout_redirected(new_stdout):
>> +save_stdout = sys.stdout
>> +sys.stdout = new_stdout
>> +try:
>> +yield None
>> +finally:
>> +sys.stdout = save_stdout
>
> I think this test could easily be tweak
eric.smith wrote:
> [EMAIL PROTECTED]
> +def stdout_redirected(new_stdout):
> +save_stdout = sys.stdout
> +sys.stdout = new_stdout
> +try:
> +yield None
> +finally:
> +sys.stdout = save_stdout
I think this test could easily be tweaked to use
test.test_support.captu
The company I work for has over the last couple of years created an
application server for use in most of our customer projects. It embeds Python
and most project code is written in Python by now. It is quite resource-hungry
(several GB of RAM, MySQL databases of 50-100GB). And of course it is
mul
This flag is exposed to python code as sys.flags.py3k_warning
So the hack added to some of the test code that I saw go by on
python-checkins isn't needed :)
Cheers,
Nick
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
--
> I think (repeatedly) testing an app through IDLE is a reasonable use case.
I don't disagree, but cleanup of logging may not be all that trivial in some
scenarios: for example, if multiple threads have references to handlers,
then after shutdown() was called, logging by those threads would fail d
On 19/03/2008, Jeff Rush <[EMAIL PROTECTED]> wrote:
> 1. What is the plan for PyPI when Python 3.0 comes out and
> dependencies start getting satisfied from distribution
> across the great divide, e.g. a 3.0-specific package
> pulls from PyPI a 2.x-specific package to meet some
> n
As I'm digging into packaging issues here at PyCon, a couple of Python 3000
related matters occur to me. As I'm new to the Python 3000 development, if
these have already been addressed in prior discussions, I apologize for your
time.
1. What is the plan for PyPI when Python 3.0 comes out and
Phillip J. Eby wrote:
>
> I'm actually happy to hear that there's this much energy available --
> hopefully some of it can be harnessed towards positive solutions.
>
> When I began developing setuptools, I often asked for the input of
> packagers, developers, etc., through the distutils-sig...
Trent Nelson wrote:
>>> Sounds like a challenge if ever I've heard one -- care to wager a beer on
>>> it?
>>> (Only applies to buildbots that are connected/online.)
>
>> Make sure you get a screen shot for OnYourDesktop if/when they *do* go
>> green!
>
> Screenshot? I'm going to buy a pack of i
+1 to assert* from me. the fail* variants always feel like
double-negatives. I also always use assertTrue instead of assert_. But
I don't care enough to argue about it. :)
On Wed, Mar 19, 2008 at 2:24 AM, Gabriel Grant <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This gem from unittest.py is pretty m
Hi all,
This gem from unittest.py is pretty much the opposite of "one obvious way":
# Synonyms for assertion methods
assertEqual = assertEquals = failUnlessEqual
assertNotEqual = assertNotEquals = failIfEqual
assertAlmostEqual = assertAlmostEquals = failUnlessAlmostEqual
a
91 matches
Mail list logo
