Re: working pylint anyone?
on 31.07.2008 11:29 Diez B. Roggisch said the following: snip The packaged version of pylint (0.13.2) fails with this error (last line): snip So - anybody out here having an actually working pylint config and can tell me what versions work together? I've become pretty dependend on it to be honest... Three installations of pylint 0.14.0 that I have access to from here: pylint.bat 0.14.0, astng 0.17.2, common 0.27.0 Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] pylint 0.14.0, astng 0.17.2, common 0.31.0 Python 2.5.2 (r252:60911, Jul 23 2008, 00:17:15) [GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] pylint 0.14.0, astng 0.17.2, common 0.27.0 Python 2.5.1 (r251:54863, Jul 11 2007, 15:07:18) [GCC 3.3.5 (Debian 1:3.3.5-13)] All of them installed using good old setup.py (times 3). easy_install does not work as you noted. Hope that helps. cheers, stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: isgenerator(...) - anywhere to be found?
on 22.01.2008 14:20 Diez B. Roggisch said the following: def isgenerator(v): def _g(): yield return type(v) == type(_g()) But I wonder why there is no such method already available? This tests for generator objects, and you could also use:: return type(v) is types.GeneratorType I think that this is pretty direct already. I also need to test for generator functions from time to time for which I use:: def _isaGeneratorFunction(func): '''Check the bitmask of `func` for the magic generator flag.''' return bool(func.func_code.co_flags CO_GENERATOR) cheers, stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: isgenerator(...) - anywhere to be found?
on 22.01.2008 16:09 Paul McGuire said the following: On Jan 22, 7:46 am, Stefan Rank [EMAIL PROTECTED] wrote: I also need to test for generator functions from time to time for which I use:: def _isaGeneratorFunction(func): '''Check the bitmask of `func` for the magic generator flag.''' return bool(func.func_code.co_flags CO_GENERATOR) cheers, stefan Might want to catch AttributeError in this routine - not all func arguments will have a func_code attribute. See below: class Z(object): def __call__(*args): for i in range(3): yield 1 for i in Z()(): print i # prints 1 three times import types print type(Z()()) == types.GeneratorType # prints 'True' print Z()().func_code # raises AttributeError, doesn't have a func_code attribute You are right about that for generator *objects*. But _isaGeneratorFunction tests for generator *functions* (the ones you call in order to get a generator object) and those must have a func_code. So in your example:: from compiler.consts import CO_GENERATOR Z().__call__.func_code.co_flags CO_GENERATOR 32 Z.__call__.func_code.co_flags CO_GENERATOR 32 You have to use __call__ directly, you can't use the code-object-flag test on the callable class instance Z(), but I think that's just as well since this kind of test should not be necessary at all, except in rare code parts (such as Diez' microthreading experiments). cheers, stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Nudge needed for rst to html
on 06.09.2007 13:16 Tim Golden said the following: I'm a bit embarrassed about this, but I've scoured the docutils docs and I can't seem to work out how to take a block of ReStructuredText and output a raw HTML fragment, ideally without a surrounding document or embedded/linked css etc. (I'm trying to allow rst in our helpdesk system which can render nicely on the web version and be readable in text). I thought that: code import docutils.core html = docutils.core.publish_string (Hello, world!, writer_name=html) /code would do the trick, but that produces an entire document with an embedded style block. try this:: import docutils.core parts = docutils.core.publish_parts(Hello!, writer_name=html) html = parts['body'] tfm: http://docutils.sourceforge.net/docs/api/publisher.html cheers, stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: What makes an iterator an iterator?
on 18.04.2007 07:39 Steven D'Aprano said the following: I thought that an iterator was any object that follows the iterator replace object with instance of a class, i.e. the relevant methods are looked up in the __class__ not in the instance (I think). I had the same troubles trying to dynamically reassign a __call__ method... protocol, that is, it has a next() method and an __iter__() method. But I'm having problems writing a class that acts as an iterator. I have: class Parrot(object): def __iter__(self): return self def __init__(self): self.next = self._next() def _next(self): for word in Norwegian Blue's have beautiful plumage!.split(): yield word Try this:: class Parrot(object): def __iter__(self): return self def __init__(self): self.__class__.next = self._next().next # see post by I V def _next(self): for word in Norwegian Blue's have beautiful plumage!.split(): yield word This works but practically forces the class to be used as a singleton... not very helpful :) Better: * use the '__iter__ returns/is a generator' way, * or if you need the object to be the iterator, implement the next method directly on the class:: class Parrot(object): def _next(self): for word in Norwegian Blue's have beautiful plumage!.split(): yield word def __iter__(self): self.generator = self._next() return self def next(self): return self.generator.next() cheers, stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Pep 3105: the end of print?
on 16.02.2007 13:02 Edward K Ream said the following: There are a tool called 2to3 that translates things like print foo to print(foo). The point of my original post was that if I want to maintain a common code base the tool must translate 'print foo' to 'print2(foo)'. I think you are misunderstanding the purpose of the 2to3 tool. It is supposed to create a new version of the code that runs on py3, while you can still run your *old* code on py2.x There won't be a common code base for all python versions. You will have to decide at what point you want to switch from developing the 2.x code (and using the 2to3 tool to support py3) to developing the py3 code. (You might then develop a 3to2 tool, but I think this discussion is getting way ahead of its time. ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: sgmllib bug in Python 2.5, works in 2.4.
on 05.02.2007 03:49 John Nagle said the following:
(Was prevously posted as a followup to something else by accident.)
I'm running a website page through BeautifulSoup. It parses OK
with Python 2.4, but Python 2.5 fails with an exception:
Traceback (most recent call last):
File ./sitetruth/InfoSitePage.py, line 268, in httpfetch
self.pagetree = BeautifulSoup.BeautifulSoup(sitetext) # parse into tree
form
File ./sitetruth/BeautifulSoup.py, line 1326, in __init__
BeautifulStoneSoup.__init__(self, *args, **kwargs)
File ./sitetruth/BeautifulSoup.py, line 973, in __init__
self._feed()
File ./sitetruth/BeautifulSoup.py, line 998, in _feed
SGMLParser.feed(self, markup or )
File /usr/lib/python2.5/sgmllib.py, line 99, in feed
self.goahead(0)
File /usr/lib/python2.5/sgmllib.py, line 133, in goahead
k = self.parse_starttag(i)
File /usr/lib/python2.5/sgmllib.py, line 291, in parse_starttag
self.finish_starttag(tag, attrs)
File /usr/lib/python2.5/sgmllib.py, line 340, in finish_starttag
self.handle_starttag(tag, method, attrs)
File /usr/lib/python2.5/sgmllib.py, line 376, in handle_starttag
method(attrs)
File ./sitetruth/BeautifulSoup.py, line 1416, in start_meta
self._feed(self.declaredHTMLEncoding)
File ./sitetruth/BeautifulSoup.py, line 998, in _feed
SGMLParser.feed(self, markup or )
File /usr/lib/python2.5/sgmllib.py, line 99, in feed
self.goahead(0)
File /usr/lib/python2.5/sgmllib.py, line 133, in goahead
k = self.parse_starttag(i)
File /usr/lib/python2.5/sgmllib.py, line 285, in parse_starttag
self._convert_ref, attrvalue)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa7 in position 0:
ordinal
not in range(128)
The code that's failing is in _convert_ref, which is new in Python
2.5.
That function wasn't present in 2.4. I think the code is trying to
handle single quotes inside of double quotes, or something like that.
To replicate, run
http://www.bankofamerica.com
or
http://www.gm.com
through BeautifulSoup.
Something about this code doesn't like big companies. Web sites of smaller
companies are going through OK.
Also reported as a bug:
[ 1651995 ] sgmllib _convert_ref UnicodeDecodeError exception, new in 2.5
John Nagle
Hi,
I had a similar problem recently and did not have time to file a
bug-report. Thanks for doing that.
The problem is the code that handles entity and character references in
SGMLParser.parse_starttag. Seems that it is not careful about
unicode/str issues.
My quick'n'dirty workaround was to remove the offending char-entity from
the website before feeding it to Beautifulsoup::
text = text.replace('#174;', '') # remove rights reserved sign entity
cheers,
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting Process Name on Win32
[BTW, there is a list/newsgroup specifically for pywin32]
on 06.09.2006 12:56 Rama said the following:
Hi,
I want to list the names of all the processes running on my
machine. I am stuck at this point and do not know how to extract the
name of a process.
Using win32process.EnumProcesses, I am able to obtain the pids of
all the processes and using win32api.OpenProcess() I have obtained a
handle to the process. However, I could not find an appropriate method
to provide me the name of the process. I went through the available
documentation on the
http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/pywin32/win32.html
site - but could not find something to help me.
Could some one please guide me on this?
This is not directly what you wanted, but it works for me::
In [1]: import win32com.client
In [2]: wmi = win32com.client.GetObject('winmgmts:')
In [3]: procs = wmi.ExecQuery('Select * from win32_process')
In [4]: for proc in procs:
...: print proc.Name
...:
System Idle Process
... [censored]
There are also python-packages that encapsulate dealing with wmi.
cheers,
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 354: Enumerations in Python
on 28.02.2006 07:50 Carl Banks said the following:
Ben Finney wrote:
This PEP specifies an enumeration data type for Python.
[snip]
Here's why I think it's not too useful to begin with: the benefits of
the enum you describe here are pretty weak.
I need to disagree heavily here :)
+1 from me for the general idea of a builtin enum.
(and for 'real world' use cases: I use this type of enum, the PEP one,
in my code regularly)
It's a pretty weak case to have a dedicated builtin to prevent
duplicates in something that changes maybe once a month, as enums tend
to change rather slowly. (At least, that's the way enums in other
languages are used, and the design you present here seems to suggest
you intend to use them that way as well.) And frankly, a unit test or
assertion could check this.
[snip]
I don't understand what you mean by 'change rather slowly'?
The dominant use case for an explicit enum is to make it clear for the
code user that the values are a separate type, and prevent errors
occurring because the abused underlying type shows through (be it
strings or integers) or at least give informative warnings for them. If
you want more than that something, like a dict, will probably be better.
recent examples from this list:
2006-01-03: http://www.nabble.com/Re%3A-Regex-anomaly-p2179421.html
2006-02-20:
http://www.nabble.com/Re%3A-Regular-expression-gone-mad-p3029028.html
The nonsensical comparisions should throw value errors.
That's a valid point.
I hope someone knowledgeable will go through the standard library and
check each flag-like thing (which is not directly dependent on an
underlying c-library idiom) against the proposed enum type.
One thing that is probably missing to allow this, is a enum-set-creation
with the | operator::
Weekdays = enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun')
daysihate = Weekdays.mon | Weekdays.thu
(and this discussion needs to move to python-dev ?)
As for the metaclass versions: For myself, the above version feels more
natural and straightforward (in the same way as the PEP author describes
it), though I understand the subclassing ideas.
But are there use cases for subclassing, that aren't better served with
a new enum or something homegrown?
Can C++/Pascal/Java enums be subclassed?
cheers,
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 354: Enumerations in Python
on 28.02.2006 12:14 Carl Banks said the following:
[snip]
It's a pretty weak case to have a dedicated builtin to prevent
duplicates in something that changes maybe once a month, as enums tend
to change rather slowly. (At least, that's the way enums in other
languages are used, and the design you present here seems to suggest
you intend to use them that way as well.) And frankly, a unit test or
assertion could check this.
[snip]
I don't understand what you mean by 'change rather slowly'?
Construct data structure on-the-fly from an XML file edited by multiple
people every day = changes rather quickly
Construct data structure from a Python file that was last edited a year
and a half ago = changes rather slowly
Typically, enums fall into the latter category. You set the enum
values, and then pretty much leave them alone, adding new values only
occasionally. (Come on, how often do the days of the week change?)
All I was saying is, changes to the enum values are infrequent enough
that having a special type just to make sure there are no duplicates is
a waste. The only justification for a built-in enum is the other stuff
you mentioned.
agreed
One thing that is probably missing to allow this, is a enum-set-creation
with the | operator::
Weekdays = enum('mon', 'tue', 'wed', 'thu', 'fri', 'sat', 'sun')
daysihate = Weekdays.mon | Weekdays.thu
(and this discussion needs to move to python-dev ?)
What's wrong with set((Weekdays.mon,Weekdays.thu))? Explicit is better
than implicit.
agreed again.
the | idea would only be for (interface) backwards compatibility.
As for the metaclass versions: For myself, the above version feels more
natural and straightforward (in the same way as the PEP author describes
it), though I understand the subclassing ideas.
But are there use cases for subclassing, that aren't better served with
a new enum or something homegrown?
Can C++/Pascal/Java enums be subclassed?
In C++, enum is a type but not a class. Same thing with Ada. Java
didn't have enums last time I checked. Don't know about Pascal.
Was more of a question for subclassing use cases in other languages.
BTW Java has an enum now, which cannot be subclassed either AFAIK. And
it's the same for (Delphi) Pascal.
I
didn't care too much about subclassing; I just thought different enum
constant that couldn't (or, rather, oughtn't) be compared probably
should be instances of a separate class. It doesn't matter much,
though.
Should something like this work:
day = Weekdays.mon
isinstance(day,Weekdays)
?
I think in the PyPI package `type(Weekdays)` is `Enum` and
`type(Weekdays.mon)` is `EnumValue`, so this would not work.
But membership testing `if day in Weekdays: ...` could do the same, and
type-checking for enum values `isinstance(day, EnumValue)` would work
(might be unpythonic though).
In the cookbook recipe `enum('..')` is a function and constructs two new
types on the fly, so the values of two different enums would be of a
different type, but you would not be able to name it easily...
cheers
--
http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website ?
on 11.01.2006 11:44 Steve Holden said the following: http://beta.python.org Very nice! Just wanted to note that the content area and the menu area overlap (leaving some content unreadable) in Opera 8.51 / WinXP str -- http://mail.python.org/mailman/listinfo/python-list
Re: 0 in [True,False] returns True
on 13.12.2005 11:39 Fredrik Lundh said the following: Duncan Booth wrote: Another reason to have a boolean type is of course to provide a cast: def isNameSet(self): return boolean(self.name) [snip] given that Python already had a function for this, that wasn't much of a reason: help(operator.truth) Help on built-in function truth in module operator: truth(...) truth(a) -- Return True if a is true, False otherwise. [snip] As operator.truth() is equivalent to bool() and as it is the only thing in operator that is not really reflecting an operator, I had a look into PEP3000 to see if (the redundant) operator.truth is going to be removed. It is not mentioned. (not that I really care, but I thought I could provide something productively new to discuss about, to end the why is bool an int? discussion ;-) stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Underscores in Python numbers
on 19.11.2005 06:56 Steven D'Aprano said the following:
[snip]
Perhaps Python should concatenate numeric literals at compile time:
123 456 is the same as 123456.
Off the top of my head, I don't think this should break any older code,
because 123 456 is not currently legal in Python.
+1
but only allow (a single ?) space(s), otherwise readability issues ensue.
The other idea of teaching int() about separator characters has
internationalis/zation issues:
In many European countries, one would naturally try::
int('500.000,23')
instead of::
int('500,000.23')
--
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Alert: Help me store constants pythonically
on 08.11.2005 17:40 Brendan said the following: [snip config/properties file needs] I've checked out ConfigParser, ConfigObj, Pickle, PyYaml and gnossis.xml.serialize, and none meet all the above criteria (though they're all neat). So I've decide to use ...drumroll please plistlib ( http://svn.python.org/projects/python/trunk/Lib/plat-mac/plistlib.py ). like myriads of others, i went through the same dance as you did (several times, several programming languages), and sadly, i did not come across plistlib.py in the python case. as a first glance inspires liking and the lib does not seem to require anything mac-specific, i would like to ask why it is not in the standard python distribution? So away I go. If anyone can suggest reasons I should avoid this approach, please let me know before I get too invested. Otherwise, this might be a reasonable avenue for standardizing Python. I second that. stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding a __filename__ predefined attribute to 2.5?
on 12.10.2005 10:02 Diez B. Roggisch said the following:
Rune Strand wrote:
Currently I have this in my scripts:
__filename__ = __file__.replace('\\', '/').rsplit('/', 1)[-1]
This is neither platform independent nor less overhead. This is:
import os
__filname__ = os.path.split(__file__)[-1]
I would say that::
import os
filename = os.path.basename(__file__)
is even more explicit.
And with one of the several existing 'path' modules it would be::
from path import path
filename = path(__file__).basename
I am sorry if I missed this on this list,
but was there a decision on the idea of including an object-oriented
path class in the standard library?
cheers,
stefan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug in string.find; was: Re: Proposed PEP: New style indexing,was Re: Bug in slice type
[snipped alot from others about indexing, slicing problems, and the inadequacy of -1 as Not Found indicator] on 31.08.2005 16:16 Ron Adam said the following: The problem with negative index's are that positive index's are zero based, but negative index's are 1 based. Which leads to a non symmetrical situations. Hear, hear. This is, for me, the root of the problem. But changing the whole of Python to the (more natural and consistent) one-based indexing style, for indexing from left and right, is... difficult. -- http://mail.python.org/mailman/listinfo/python-list
regexps with unicode-aware characterclasses?
Hi all,
in a python re pattern, how do I match all unicode uppercase characters
(in a unicode string/in a utf-8 string)?
I know that there is string.uppercase/.lowercase which are
'locale-aware', but I don't think there is a all locales locale.
I know that there is a re.U switch that makes \w match all unicode word
characters, but there are no subclasses of that ([[:upper:]] or
preferably \u).
Or is there a module/extension to get that?
There is the module unicodedata, but it has no unicodedata.uppercase
that would correspond to string.uppercase.
wishful thinking
re.compile('|'.join([x.encode('utf8') for x in unicode.uppercase]))
or::
re.compile('(?u)[[:upper:]]')
or::
re.compile('(?u)\u')
for the latter two, to work on utf-8 strings, would I have to set the
defaultencoding to utf-8?
/wishful thinking
--
http://mail.python.org/mailman/listinfo/python-list
Re: Advanced concurrancy
on 04.08.2005 11:15 Matt Hammond said the following: Hi Stefan, It seems as though all components basically have to do busy waiting now. You are right - components are, for the most part, busy-waiting. Which is not a good thing! So do you plan on including a kind of scheduler-aware blocking communication (like the `channels` of the `tasklets` in stackless)? [snip] There is basic support for components to block, by calling the self.pause() method. From the next yield, this blocks further execution until data arrives on any inbox. [snip] ah, i was searching for blocking on a specific inbox, but this is actually a saner approach i think. why should you block on one inbox and ignore data coming in on another... There are quite probably better mechanisms around - hence the distinction, in the code, between microprocesses and components. We'd be very interested if yourself or other people want to play with alternative communication blocking mechanisms. i think in-out channels is probably the best way for easy to manage comunicating processes. I'd hope that even if the components and postboxes model doesn't work out in the long run, the underlying generator based microprocesses code could still be of some value to others! yes both levels will (it will take some time before i can use it here...), i think of it as a more complete version of some of the stackless features in standard python. (thanks again by the way) the magic.greenlets have 'cooperative microprocesses', but lack the more pipe-like communication facilities and the independency of the generators+scheduler based approach. the coroutine support in future pythons (see the generator PEPs) will probably make this easier... maybe:: next_inbox_to_read = yield blockon(inbox1, inbox2) this communication infrastructure is definitely a Good Thing (TM), the same holds for a standard environment or registry (wassitsname, your CAT thing) as you need at least one well-known point of reference in a 'distributed' system. dreamingmode now if someone could only cut the gordian knot of the GlobalInterpreterLock to make all this really concurrent... and then, when she's at it, allow transparent distribution of components in a network... ;-) /dreamingmode -- http://mail.python.org/mailman/listinfo/python-list
Re: Advanced concurrancy
on 04.08.2005 00:36 Michael Sparks said the following: Peter Tillotson wrote: I'm quite interested in the mini version and also using the modules as mobile code rather than installing it formally. I'll document it slightly better and post up on the website in the next 48 hours or so. In the meantime, the optimisation test which includes a slightly modified mini-axon can be found here: http://cvs.sourceforge.net/viewcvs.py/kamaelia/Sketches/OptimisationTest/ Specifically the file simplegame.py. Hi, sorry to intrude here. I looked at Kamaelia (Axon actually) recently and I liked it, what I did miss in the code (maybe I just did not find it) is a blocking way for send-ing and recv-ing from in/outboxes that the scheduler is aware of. It seems as though all components basically have to do busy waiting now. So do you plan on including a kind of scheduler-aware blocking communication (like the `channels` of the `tasklets` in stackless)? (as you have a postman already - not a bad idea i think if you compare with multi-agent-systems theory (see jade) - it could be responsible for alerting the scheduler of box.has_data) Cheers, Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: A replacement for lambda
on 30.07.2005 10:20 Paolino said the following: why (x**2 with(x))(x**3 with(x)) is not taken in consideration? If 'with' must be there (and substitue 'lambda:') then at least the syntax is clear.IMO Ruby syntax is also clear. I am sorry if this has already been proposed (I am sure it has). Why not substitue python-lambdas with degenerated generator expressions:: (lambda x: func(x)) == (func(x) for x) i.e. a one time callable generator expression (missing the `in` part). The arguments get passed into the generator, I am sure that can be combined with the PEP about passing args and Exceptions into a generator. -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
[__div__ for .joinpath()] on 29.07.2005 04:48 Tony Meyer said the following: I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. So far there seem to have been a few +0s, but no +1s... What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) In what way is this much better? because of the 'object-orientedness'. i hope we agree on that (that's the reason for a path PEP?). the first is only sugar for the explicit:: path(__file__).dirname().joinpath(blablablabalbal) and as i said +0 operator overloading is only good if it's intuitive for the majority. (or Guido i suppose, in case this majority-person does not show up) [snip] Would you really choose this: p = Path() / build / a / very / very / long / path (Path() is the current dir I think) Over this: p = Path(os.path.join(build, a, very, very, long, path)) ? A saving of six characters, and the second one is a lot clearer. If there was a os.path.joinPath (or whatever name) function that returned a Path object rather than a string, then you'd get: p = joinPath(build, a, very, very, long, path) Which is better (clearer, more concise) than either of the others, IMO. actually for explicitness i would choose: (original jorendorff):: p = path(build).joinpath(any, path, you, can, imagine) or otherwise maybe:: p = path(alpha) / and / omega -- http://mail.python.org/mailman/listinfo/python-list
Re: [path-PEP] Path inherits from basestring again
on 25.07.2005 10:44 Michael Hoffman said the following: Reinhold Birkenfeld wrote: Tony Meyer wrote: Do people really like using __div__ to mean join? Of course, one can use joinwith() if he doesn't like '/'. Personally, I'm -0 on __div__, but I suppose if anyone here claimed to have used in the past, rather than it just being some novelty that might be a good idea, that would be good enough for keeping it. I, herewith, claim to have used it in the past. But I am indifferent as to if its needed, it just looks natural to me. What I use quite often is:: path(__file__).dirname() / somesiblingfileiknowisthere you do not have to think about trailing slashes or absolute vs. relative. and its much better than:: from os.path import * join(dirname(__file__), somesiblingfileiknowisthere) __div__ is actually very convenient to build / a / very / very / long / path (of course assuming the parts are strings not known initially...) -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
on 22.07.2005 00:21 Michael Hoffman said the following: Reinhold Birkenfeld wrote: John Roth wrote: Why did Guido want a PEP? He said, Whoa! Do we really need a completely different mechanism for doing the same stuff we can already do? The path module seems mostly useful for folks coming from Java who are used to the Java Path class. What is this Java Path class? I have been STFWing and have found nothing on it in the. Indeed if you search for Java Path class (with quotes) almost half of the pages are this message from Guido. ;) Any Java hackers here want to tell us of the wonders of the Java Path class? no such thing exists. there is only the `File` class that incorporates a little bit of the `path` functionality and some of the python built-in `file` functionality. my little self would actually propose to make *path* a built-in type as an intermediate between file and basestring/str/unicode (the latter is probably needed). *ducks* -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP on path module for standard library
on 22.07.2005 16:14 George Sakkis said the following: Duncan Booth [EMAIL PROTECTED] wrote: Personally I think the concept of a specific path type is a good one, but subclassing string just cries out to me as the wrong thing to do. In other words, to me a path represents something in a filesystem, the fact that it has one, or indeed several string representations does not mean that the path itself is simply a more specific type of string. [snip] practicality-vs-purity decision. You're right, conceptually a path HAS_A string description, not IS_A string, so from a pure OO point of view, it should not inherit string. Java has `File` which mixes the concepts an object in the filesystem and a structured locator for such objects (in a hierarchical fs) that might or might not correspond to an object that is actually there. `file` and `path` separate that. I think this is very reasonable. (It would be nice to get `path`(s) easily from a `file`, at the moment there is only file.name if I'm not mistaken). And a `path`, to me, actually IS_A string (unicode string) that happens to have special behaviour (such as os dependent quirks like a pathseparator that automatically get translated, comparable to '\n' used internally in strings translated to '\n'|'\r\n') stefan -- http://mail.python.org/mailman/listinfo/python-list
