s that would break this into multiple statements.
[inspired by a recent python-list question]
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
return self(
> binascii.unhexlify(data))".
Am I the only one who finds the use of "self" on a classmethod to be
incredibly confusing? Can we please follow PEP 8 and use "cls"
instead?
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
[Thomas Wouters]
>>> [Subclassing string] is my only problem with the PEP. It's all very nice
>>> that subclassing from string makes it easier not to break things, but
>>> subclassing implies a certain relationship.
[Michael Hoffman]
>> This is the
s not use
isinstance() or any of the string methods that are now gone.
http://groups.google.com/group/comp.lang.python/browse_thread/thread/1f5bcb67c4c73f15
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
Python-Dev
ion is
pretty comparable, despite it being in the interpreter rather than in
the stdlib. And some of us have come to love that, too.
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
Python-Dev mailing list
Python-Dev@python.org
t;
In particular the points about Path being able to be a drop-in
replacement for str/unicode are useful ones, and explain the use of
joinpath() etc. It is really useful that I can use a Path anywhere I
might have used an str and not have to worry about the conversions.
--
Michael Hoffman <[EM
for concatenation and addition,
> and these are far more ambiguous from context -- but still it doesn't
> cause that many problems.
I was initially -0 on / but I have found it quite useful and a lot
simpler than a lot of joinpath()s over time.
So +1 on / for me.
--
Michael Hof
[Wolfgang]
> Or should we switch to camelCase with lowercase first letter ?
> As most other Languages prefer this (Java, C#, C++, ...)
They also use curly braces instead of indentation to indicate block
structure. Maybe we should switch to that too.
--
Michael Hoffman <[EMAIL
[Jim Fulton]
>>> Personally, I don't find the stdlib/external distinction to be useful.
[Michael Hoffman]
>> It's useful because it allows one to quickly see all the prerequisites
>> need to be installed in one place.
[Jim Fulton]
> Sure, if you only have one
be installed in one place.
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
tions that are integrated into the core and
> maintained as part of it.
The same could be said of a lot of other projects that use the
"contrib" convention. I have a much better idea of what "contrib"
means than "kits" or "external."
--
M
ets, buffers? sure. stdout? Almost never.
Almost every program I write produces its output mainly to stdout. And
I probably use print half the time to produce this output (the rest is
done mostly with csv).
GUI widgets? Who needs 'em?
--
Michael Hoffman <[E
/lib/node114.html
> http://docs.python.org/lib/re-objects.html
Dare I ask whether the uncompiled versions should be considered for
removal in Python 3.0?
*puts on his asbestos jacket*
--
Michael Hoffman <[EMAIL PROTECTED]>
European Bio
is?
I e-mailed Jason earlier this week before submitting the RFE. He said
that "I'd like to see path (or something like it) in the standard
library." He also said he didn't have time to write a PEP at the
moment, but that I should feel free to do so.
As for me, I'm happy
On Mon, 27 Jun 2005, Phillip J. Eby wrote:
> At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
>> os.getcwd() returns a string, but path.getcwd() returns a new path
>> object.
>
> In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
> At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
>> On Sun, 26 Jun 2005, Phillip J. Eby wrote:
>>
>>> * drop getcwd(); it makes no sense on a path instance
>>
>> Personally I use path.getcwd() as a class meth
e to use os.path
anymore.
Reinhold Birkenfeld wrote:
> One more issue is open: the one of naming. As "path" is already the
> name of a module, what would the new object be called to avoid
> confusion? pathobj? objpath? Path?
I would argue for Path. It fits with the recent
he last
three years and have loved almost every minute of it. I've written
sequence alignment algorithms in Pyrex, glue to genome database APIs
in Jython, and a whole lot of other stuff using CPython. We run Python
on a 1145-CPU compute farm that consists of Alpha/Tru64 and
Intel/Linux boxes.
--
18 matches
Mail list logo
