then sorting a list with
sets would raise an exception, a much more understandable failure mode
than getting back a list in arbitrary order.
I agree. This is a cost of overloading operators with domain specific
meanings.
All the best,
Michael Foord
Jean-Paul
legitimate design rule for the stdlib to follow from now on, but
in the case of unittest it's too late to change it back (and it's a
minor price to pay to learn this lesson and to have Michael
maintaining unittest like he has been, plus we could consider using
the new structure so that the
people it seems, prefer source files to be structured in a
way to match the public API. In the case of unittest Michael didn't.
He did ask python-dev if it was okay to do what he did, we all kept
quiet, and now we have realized that most of us prefer to have files
that mirror the API; lesson learned
ady some consumers of the new package
structure.
As the maintainer of unittest I'd like to say that in the absence of
clear consensus that the merger should happen, or a fiat from the BDFL,
the merger won't happen. I believe that this is standard Python
development process.
All
On 02/11/2010 23:34, Michael Foord wrote:
On 02/11/2010 23:00, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
wrote:
On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
I think the issue here is that the file structure of the code no
longer matches the public API documented
is/pysmell/
All the best,
Michael
Raymod
___
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/fuzzyman%40voidspace.org.uk
It still presents a single "big-ball-of-mud"
namespace, only rather than implemented in a single file, it is now
swept in from eight different files.
Are you saying that it has become a pile of medium-sized balls of mud?
I would like to say thanks for the mud, Michael! It's high
On 03/11/2010 02:57, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 19:50, Michael Foord wrote:
On 02/11/2010 02:35, Brett Cannon wrote:
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrouwrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolskywrote:
While I appreciate your and
believe they implicitly end up included in any pickles involving
affected classes (I seem to recall we've been bitten by that before
when moving things around).
Yes, since unittest.TestCase is still available (as are all the names).
I believe so anyway...
Michael
Cheers,
Nick.
--
On 03/11/2010 14:17, Antoine Pitrou wrote:
Le mercredi 03 novembre 2010 à 14:16 +, Michael Foord a écrit :
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big commitment
On 03/11/2010 14:26, Michael Foord wrote:
On 03/11/2010 14:17, Antoine Pitrou wrote:
Le mercredi 03 novembre 2010 à 14:16 +, Michael Foord a écrit :
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a
On 03/11/2010 14:53, Eric Smith wrote:
On 11/3/10 10:16 AM, Michael Foord wrote:
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names
On 03/11/2010 14:53, Eric Smith wrote:
On 11/3/10 10:16 AM, Michael Foord wrote:
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names
On 03/11/2010 19:48, Jesse Noller wrote:
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou wrote:
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord wrote:
Antoine is firmly of the opinion that making TestCase instances
unpickleable is a feature...
Apparently you didn't really understand me
on that particular issue.
All the best,
Michael
Geremy Condra
___
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/fuzzyman%40voidspace.o
mply pick a directory and unittestgui will
discover and run all the tests it finds. It would be nice if it provided
more diagnostic information on tests it ran (clicking through test
results) but these can be added later.
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
READ CAREFULLY.
lied. That way the old name does get the
bugfixes but is still deprecated.
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
but we want to exclude it from the API"...
This would be a good approach to clarifying the public API of standard
library modules. At least that way we could work towards a consistent
policy.
All the best,
Michael
Alternatively you could make the old name an alias for the new one
with a
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
wrote:
..
If you deprecate it then you don't *have* to fix bugs in it. If we know it
is used then we can't remove it without deprecation.
What about the maintenance branch?
So you have a bug in the module that can only be fixed in a fu
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord wrote:
..
So you have a bug in the module that can only be fixed in a function you
want to deprecate?
No, I have a bug in a function that I want to deprecate. You said I
don't need to fix it if I add a deprecation warning. However, as far
On 08/11/2010 19:00, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 04:09, Michael Foord wrote:
Hello all,
Now that unittest has test discovery, Mark Roddy has been working on
resurrecting the old GUI test runner (using Tkinter):
https://bitbucket.org/markroddy/unittestgui
This was part of the
On 08/11/2010 19:28, Alexander Belopolsky wrote:
On Mon, Nov 8, 2010 at 7:09 AM, Michael Foord wrote:
..
I'd like to propose adding [unittestgui] to Python in Tools/ and am
volunteering to
maintain it.
Why not adding it under Lib/unittest/?
I really don't want to make Tk a depe
ace despite become a package
under the hood.
Look again. :-)
Benjamin did the refactoring into a package and he obviously dislikes
"import *" as much as me. If he had used "import *" I would have changed
it anyway, but he didn't.
We also define a __all__ to make the exp
be offered,
but that the old will be left in-place so that tons of existing code won't
break). Likewise, with the unittest clean-ups, I'm expecting that Michael will
introduce aliases when fixing-up mis-named methods, rather than break code that
uses the existing names.
So it is
referring to certain packages (which shall remain
nameless since I don't feel like googling to find one) whose
documentation recommends the 'from import *' methodology.
Contenders include popular libraries like fabric and django:
http://docs.fabfile.org/0.9.2/usage/fabfiles.html
ht
On 11/11/2010 05:41, Alexander Belopolsky wrote:
On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam wrote:
..
On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
So it is obvious that we don't have a clearly stated policy for what
defines the public API of standard library modules.
How about m
On 11/11/2010 13:39, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2010 08:23 AM, Alexander Belopolsky wrote:
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
wrote:
..
Is it OK to add __all__ to such modules that does not include all
names not starting with an
constants. (And there the issue is not whether we can
remove but how we do it.)
Michael
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTI
ion.
You mean runtime automation, e.g. creating __all__ on the fly omitting
underscored names?
Writing code to generate a __all__ that duplicates the default behaviour
seems redundant to me.
Michael
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you
l be decided on a case-by-case basis and that
names *obviously* never intended to be public may be changed if it is
believed that they aren't (or really shouldn't be) in use.
All the best,
Michael Foord
I also have a similar question about C API. Here, in absence of
__all__, the
opers - the more
important decision is codifying how we decide what words need to go in
the dictionary (to continue to torture the analogy).
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
+1
This sounds like the right approach to me.
All the best,
Michael
A similar note could be placed in the C API documentation (with a
reference to the detailed policy in PEP 7, perhaps REsTify'ing that
PEP in the process in order to link directly to the naming convention
section
On 17/11/2010 12:37, Łukasz Langa wrote:
Am 17.11.2010 12:57, schrieb Michael Foord:
On 17/11/2010 11:45, Nick Coghlan wrote:
The definition of the public/private policy in all its gory detail
should be in PEP 8 as Guido suggests.
+1
Guido did not said that, though.
I think that is a
On 17/11/2010 13:21, Fred Drake wrote:
2010/11/17 Michael Foord:
So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of t
On 17/11/2010 13:31, Łukasz Langa wrote:
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are
higher. (They run the risk of contradicting each other, if you want
to
future if a name looks public users can have more confidence
that it actually is...
Obviously what to do about modules that don't follow these rules
currently is a big part of it (and how the discussion started).
All the best,
Michael
when reading the source code or exploring the API in t
open. I’d put open in __all__.
"import *" would then override the builtin open. A good reason not to
use "import *" I guess, but also a good reason not to create names that
shadow builtins.
All the best,
Michael
Regards
___
...
"The public names defined by a module are determined by checking
the module’s namespace for a variable named __all__"
If we decide that __all__ is purely for "import *" we should refine the
use of the word public on this page.
All the best,
Michael Foord
rs;
no members of a package or class whose name begins with a leading
underscore are public
It is still good practise that public APIs *should* be documented (and
*should* have docstrings). There is however no corollary that private
APIs should not be documented (and they may have docstrings).
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But th
class and the mro are the only two examples I
can think of (klass.__mro__ and instance.__class__ - and they are noted
in the docs?) but aren't metaclass specific.
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
If they fail to unpickle
that is a bug in pickle and not in unittest. *However*, the test is very
easy to extend to what you suggest so I have done it.
All the best,
Michael
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@
On 20/11/2010 16:01, Nick Coghlan wrote:
On Sun, Nov 21, 2010 at 1:29 AM, Michael Foord
wrote:
Can you give an example of code in a metaclass that may be executed by
getattr_static? It's not that I don't believe you I just can't think of an
example. Looking up the class and
On 20/11/2010 15:59, Antoine Pitrou wrote:
Le samedi 20 novembre 2010 à 15:48 +, Michael Foord a écrit :
On 20/11/2010 15:42, Antoine Pitrou wrote:
On Sat, 20 Nov 2010 16:34:26 +0100 (CET)
michael.foord wrote:
+
+def testPickle(self):
+# Issue 10326
+
+# Can'
On 20/11/2010 16:06, Michael Foord wrote:
On 20/11/2010 16:01, Nick Coghlan wrote:
[snip...]
The retrieval of __class__ is a
normal lookup on the object, so it can trigger all of the things
getattr_static is trying to avoid (unavoidable if you want to support
proxy classes at all), and the
) but gain readability. Comparability may be a requirement
- of course if Python had an Enum type we could use that and have both.
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release m
that can be or'd together and
still have a decent repr.)
Michael
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/
would even be
+1 on making warnings errors for regrtest but that seems to be
unpopular on #python-dev.
Enabling it for regrtest makes sense. For unittest I still think it is a
choice that should be left to developers.
Michael
Best regards,
Łukasz Langa
is that
warnings are for developers, and so are tests...
Michael
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements
implements their own private
_Constant class).
Time to revisit the PEP?
All the best,
Michael
[1] https://launchpad.net/flufl.enum
Cheers,
Nick.
--
http://www.voidspace.org.uk/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is certainly more interest now
On 23/11/2010 14:42, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old ones (including having the same underlying
value and comparing equal to it).
In many cases it is
On 23/11/2010 15:01, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 08:52 -0600, Benjamin Peterson a écrit :
2010/11/23 Antoine Pitrou:
On Tue, 23 Nov 2010 14:24:18 +
Michael Foord wrote:
Well, for backwards compatibility reasons the new constants would have
to *behave* like the old
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant
On 23/11/2010 16:05, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:40 +, Michael Foord a écrit :
On 23/11/2010 15:30, Antoine Pitrou wrote:
Le mardi 23 novembre 2010 à 15:15 +, Michael Foord a écrit :
There are still two reasonable APIs (unless you have changed your mind
and
On 23/11/2010 15:37, ben.cottr...@nominum.com wrote:
On Tue, 23 Nov 2010 15:15:29 +, Michael Foord wrote:
There are still two reasonable APIs (unless you have changed your mind
and think that sticking with plain integers is best), of which I prefer
the latter:
SOME_CONST = Constant
On 23/11/2010 16:27, Barry Warsaw wrote:
On Nov 23, 2010, at 01:50 PM, Michael Foord wrote:
Right. As it happens I just submitted a patch to Barry Warsaw's enum package
(nice), flufl.enum [1], to allow namedtuple style creation of named
constants:
Thanks for the plug (and the nice
ckwards compatibility
constraints) where you don't need to use integers (i.e. not wrapping a C
library) that's a great suggestion:
flags = {'FOO', 'BAR'}
Michael
Regards
Antoine.
___
Python-Dev mailing list
Pyt
On 23/11/2010 14:16, Nick Coghlan wrote:
On Tue, Nov 23, 2010 at 11:50 PM, Michael Foord
wrote:
PEP 354 was rejected for two primary reasons - lack of interest and nowhere
obvious to put it. Would it be *so bad* if an enum type lived in its own
module? There is certainly more interest now
On 24/11/2010 14:08, Nick Coghlan wrote:
On Wed, Nov 24, 2010 at 10:30 PM, Michael Foord
wrote:
Based on a non-exhaustive search, Python standard library modules currently
using integers for constants:
Thanks for that review. I think following up on the "NamedConstant"
idea may
scope), you could say:
def foo(bar, baz):
from module import *
...
Not in Python 3 you can't. :-)
That's invalid syntax, import * can only be used at module level. This
makes *testing* import * (i.e. testing your __all__) annoying - you have
ed constant *should* be added, and what the feature set
should look like.
All the best,
Michael
ev += '''
%s = constant_%s( %s, '%s' )
'''
ev = ev % ( typ, typ, typ, name, typ, repr( val ), name )
print( ev )
exec( ev, globals())
constant(&
the Python policy was that English speakers wrote
documentation in English and American speakers wrote documentation in
American and that we *don't* insist on US spellings in the Python
documentation?
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accept
3.2 and 2.7 (and didn't exist in 3.1)
in this respect.
Features new in Python 3.2 that didn't exist in 3.1 should have a
versionadded:: 3.2 tag.
Michael
Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
On 27/11/2010 10:51, Nick Coghlan wrote:
On Thu, Nov 25, 2010 at 3:41 AM, Michael Foord
wrote:
Can you explain what you see as the difference?
I'm not particularly interested in type validation but I like the fact that
typical enum APIs allow you to group constants: the generated con
On 27/11/2010 15:04, Nick Coghlan wrote:
On Sat, Nov 27, 2010 at 10:52 PM, Michael Foord
wrote:
I just resign myself to having to spell words like colour and
serialise wrong when I'm working on Python. Compared to the
adjustments the non-native English speakers have to make, I figur
ndard
library, otherwise we can just point people at one of the several
existing packages.
All the best,
Michael Foord
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers ar
x27; I guess, returning the constants themselves
Some of the optional features couldn't later be added without backwards
compatibility concerns (I think the type checking features and requiring
unique values for example). We should at least consider these if we are
to make adding them later
On 28/11/2010 16:28, Michael Foord wrote:
[snip...]
I don't think there are *many* competing features, in fact as far as
feature requests on python-dev go I think this is a relatively
straightforward one with a lot of *agreement* on the basic functionality.
We have had various discus
On 28/11/2010 17:05, Michael Foord wrote:
[snip...]
It is sensible if flag values are only powers of 2; we could enforce
that or not... (Another one for the optional feature list.)
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that
On 28/11/2010 18:05, Steven D'Aprano wrote:
Michael Foord wrote:
Another 'optional' feature I omitted was Phillip J. Eby's suggestion
/ requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objecti
spx
If you're not aware that your code may be run on non-US computers this
is a trap for the unwary. If you *are* aware then it is very useful.
An alternative overload allows you to specify the culture used to do the
conversion:
http://msdn.microsoft.com/en-us/library/t9ebt447.aspx
Mi
t
it may be otherwise:
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.aspx
See DigitSubstitution on that page. I would have to try it to be sure
and I don't have a Windows VM in convenient reach right now.
All the best,
Michael
Regards,
Martin
--
http://ww
Devanagari or
Bengali digits? And if so, an arbitrary mix of those and indo-arabic
digits?
Haha. Go and try it yourself. :-)
Michael
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
a
On 29/11/2010 00:48, Nick Coghlan wrote:
On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord
wrote:
For wrapping mutable types I'm tempted to say YAGNI. For the standard
library wrapping integers meets almost all our use-cases except for one
float. (At work we have a decimal constant as it ha
ompat policy for that will be a short-lived pain, and distutils itself
is getting only infrequent bugfixes *anyway*, right? I defer to Tarek on
that particular decision.
All the best,
Michael
If I remember correctly, the rationale for
code compat in distutils is that people may copy distutils
haracter reported in the error message!)
If you think non-ASCII digits are not difficult to support, please
contribute to the following tracker issues:
Would moving this functionality to the locale module make the issues any
easier to fix?
Michael
http://bugs.python.org/issue10581
(
n on Python 3. If they simply shell out to
mercurial that wouldn't be the case.
Michael
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
pted to go through a single release of deprecation.
You can add a test that the names are gone if the version of Python is
3.3. When the tests start failing the code and the tests can be ripped out.
All the best,
Michael
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this
Things are getting very much better, but happening in distutils2 not
distutils.
All the best,
Michael Foord
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
putting our support and energy into distutils2 rather than
pining for evolution of distutils.
Michael
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
On 02/12/2010 23:51, Amaury Forgeot d'Arc wrote:
Hi,
2010/12/3 Michael Foord <mailto:fuzzy...@voidspace.org.uk>>
On 02/12/2010 23:01, "Martin v. Löwis" wrote:
[snip...]
I'm just getting tired having to talk to
five projects just t
Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> Client-side web scripting tends to have a callback/continuation-ish
> concurrency style because it has to deal with network transactions
> (which can stall for long periods of time) in a user interface that
> is expected to stay always responsive. The Fir
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote:
>> didn't draw much applause. It certainly gave me the impression that
>> many changes in Python are advocated and welcomed by only a small
>> fraction of users.
>
> The benefits of changes a
On 7/5/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 7/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > From actual users of
> > the language I get more complaints about the breakneck speed of
> > Python's evolution than about the brokenness of the current language.
>
> Guido,
>
> I'm
No real time to respond in detail here, but one small comment.
[EMAIL PROTECTED] writes:
> I see some responses to that post which indicate that the specific bug will be
> fixed, and that's good, but there is definitely a pattern he's talking about
> here, not just one issue. I think there is a
[EMAIL PROTECTED] writes:
> I just would have appreciated the opportunity to participate in the
> discussion before the betas were out and the featureset frozen.
I think something that has happened to some extent with this release
is that there was a long-ish period where stuff got discussed and
ugh third
part extensions like EasyExtend or Logix. (Effectively implementing a
separate compiler.)
Readability (one way to do it...) are a central part of the Python
philosophy. This philosophy means that it is important that code written
by one developer should be readable by others.
Your su
system
would be interprocess communication (?) with a trusted interpreter
communicating with an un-trusted one. Would the communication layer need
to be implemented as a C extension, or will a standard Python API be
possible ? Hmmm maybe I should read your doc. :-)
Michael Foord
http://www.voidspace
Michael Foord wrote:
> Brett Cannon wrote:
>
>> After various people suggesting object-capabilities, takling with Mark
>> S. Miller of the E programming language, and the people Mark works
>> with at HP Labs (who have been giving talks every week during this
>>
iment, but tonight I will
try uninstalling all my Python 2.5 stuff and re-installing just 2.5b2. I
will see what dlls are present, run the interpreter a few times, and
test a simple script with shutil.copytree.
All the best,
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
Thomas Heller wrote:
> Michael Foord schrieb:
>
>> Hello all,
>>
>> There may be a reasonable cause for this (i.e. it is likely to be my
>> fault) - but it is consistent across two different machines I have tried
>> it on.
>>
>> With Pytho
The next PyPy sprint will happen in the nice city of
Limerick in Ireland from 21st till 27th August.
(Most people intend to arrive 20th August).
The main focus of the sprint will be on JIT compiler works,
various optimization works, porting extension modules,
infrastructure works like a buil
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >
>> > Yes, I definitely think dropping the X would make the warning go away.
>> > Do we want to check for a NULL pointer and raise an exception? The
>> > docs don't address the issue, so I th
ySub(self, o):
return -self.build_Const(o.getChildren()[0])
def build_UnaryAdd(self, o):
return self.build_Const(o.getChildren()[0])
def unrepr(s):
if not s:
return s
return Builder().build(getObj(s))
HTH
Michael Foord
[1] http://www.void
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Friday 28 July 2006 15:32, Raymond Hettinger wrote:
>> I suggest that there be a third beta release and that we then wait
>> just a bit before going final.
>>
>> The bugs that were found and fixed in the first two beta releases
>> suggest that Py2.5
David Hopwood <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>
gt; New version of miniconf (version 1.2.0) is out [1][2], including a
> unrepr() function; that's the only change this time.
>
> Michael Foord wrote:
>
>> ConfigObj [3] gained an 'unrepr' mode a while back. The code is simple,
>> and originally came fr
shutil.copytree is broken on windows without it.
All the best,
Michael Foord
[1] Bugfix supplied by Thomas Heller and is attached to the sourceforge
bug report.
[2] And consistently off in a weird way FWIW...
76a77,103
>
> def test_copytree_simple(sel
rst version yielded the
expected results.
I would appreciate option 2 which retains compatibility but warns that
the construct is bad. I will accept any of the options, as it's clear
that floats don't make sense. It's just unfortunate that the previous
implementation let them through in a wa
701 - 800 of 1851 matches
Mail list logo
