Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
on 2009-03-27 05:17 P.J. Eby said the following: At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote: You can't expect to improve something like that by stuffing yield-from into the existing framework, because the point of yield-from is to render the framework itself unnecessary. But it doesn't. You still need *something* that processes the yielded values, since practical frameworks have various things to yield "to" - i/o, time, mouse clicks, whatever. Correctly dealing with the call stack part is tedious to implement, sure, but it's not really the focal point of a microthreading framework. I can chime in here with a use case, if an unusual one. I implemented just such a framework based on generator syntax for my thesis work to model the behaviour of software agents as a collection of interacting activities (microprocesses). The top layer is based on Twisted (similar to its _inlineCallbacks) and different schedulers decide on what to do with yielded values. This is really very similar to Philip Eby's code, the main difference being that one uses a generic function yield_to as an extension point and the other one uses (subclasses of) Deferreds. You can handle the call stack in the Deferred-based case just as clumsily as in the other :-). And in my system, the "call stack" (i.e. the hierarchy of active microprocesses) and how it can be manipulated by the agent is actually the interesting part. Usually, you need to have some way to control which microthreads are actually to be executing, vs. the ones that are waiting for a particular time, an I/O operation, or some other sort of event. None of that stuff goes away just by taking care of the call stack. Yes. However, the valuable addition that an explicit yield from syntax would provide for my use case is a way to explicitly distinguish between subgenerators just for the sake of refactoring code vs. sub-"processes". I could remove quite some duplication from my current code. Additionally, as noted in the PEP, it would open the path for optimisations of the refactoring cases. I also think that a separation of handling the generator call stack and handling yielded values improves the situation for scheduling/trampoline authors conceptually. Just my 0.02€ cheers, stefan ___ 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/archive%40mail-archive.com
[Python-Dev] urllib.quote and unicode bug resuscitation attempt
Hi,
urllib.quote fails on unicode strings and in an unhelpful way::
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib
>>> urllib.quote('a\xf1a')
'a%F1a'
>>> urllib.quote(u'ana')
'ana'
>>> urllib.quote(u'a\xf1a')
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\urllib.py", line 1117, in quote
res = map(safe_map.__getitem__, s)
KeyError: u'\xf1'
There is a (closed) tracker item, dated 2000-10-12,
http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=216716&func=detail
and there was a note added to PEP-42 by Guido.
According to a message I found on quixote-users,
http://mail.mems-exchange.org/durusmail/quixote-users/5363/
it might have worked prior to 2.4.2.
(I guess that this changed because of ascii now being the default encoding?)
BTW, a patch by rhettinger from 8 months or so ago allows urllib.unquote
to operate transparently on unicode strings::
>>> urllib.unquote('a%F1a')
'a\xf1a'
>>> urllib.unquote(u'a%F1a')
u'a\xf1a'
I suggest to add (after 2.5 I assume) one of the following to the
beginning of urllib.quote to either fail early and consistently on
unicode arguments and improve the error message::
if isinstance(s, unicode):
raise TypeError("quote needs a byte string argument, not unicode,"
" use `argument.encode('utf-8')` first.")
or to do The Right Thing (tm), which is utf-8 encoding::
if isinstance(s, unicode):
s = s.encode('utf-8')
as suggested in
http://www.w3.org/International/O-URL-code.html
and rfc3986.
cheers,
stefan
___
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/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt
on 12.07.2006 07:53 Martin v. Löwis said the following: > Anthony Baxter wrote: >>> The right thing to do is IRIs. >> For 2.5, should we at least detect that it's unicode and raise a >> useful error? > > That can certainly be done, sure. > > Martin That would be great. And I agree that updating urllib.quote for unicode should be part of a grand plan that updates all of urllib[2] and introduces an irilib / urischemes / uriparse module in 2.6 as Martin and John J Lee suggested. =) cheers, stefan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unicode bug resuscitation attempt
on 13.07.2006 10:26 Mike Brown said the following:
> Stefan Rank wrote:
>> on 12.07.2006 07:53 Martin v. Löwis said the following:
>>> Anthony Baxter wrote:
>>>>> The right thing to do is IRIs.
>>>> For 2.5, should we at least detect that it's unicode and raise a
>>>> useful error?
>>> That can certainly be done, sure.
> Put me down as +1 on raising a useful error instead of a KeyError or whatever,
> and +1 on having an irilib, but -1 on working toward accepting unicode in the
> URI-oriented urllib.quote(), because
> See, right now, quote('abc 123%') returns 'abc%20123%25', as you would
> expect.
> Similarly, everyone would probably expect u'abc 123%' to return
> u'abc%20123%25', and if we were to implement that, there'd probably be no
> harm
> done.
Well, originally, I would have expected it to return a byte str(ing),
BUT
I am now converted and think it is best to raise a TypeError for
unicode, and leave the encoding decisions to higher level code.
So I'll repeat the "patch" #1, slightly modified::
if isinstance(s, unicode):
raise TypeError("quote expects an encoded byte string as argument")
Is it safe to assume that code that breaks because of this change was
already broken?
stefan
___
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/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
on 31.03.2007 22:39 Guido van Rossum said the following: > If you ask me, having it hosted by Trent is probably more helpful for > its popularity than putting it in the Python source distro; the Tools > directory is mostly a poorly-maintained collection of trivia I wrote > many years ago that is now quietly gathering dust. Some time ago, I posted a `feature request`_ about which.py including the proposal to put it into the std-lib as ``which`` or ``os.which`` to allow programmatic use and:: python -m which ... This should take care of the visibility problem. ;-) However, there are several todos_, including tests and docs, before this can even be considered. I am afraid I did not have any time to work on it yet. cheers, stefan .. _feature request: http://sourceforge.net/tracker/index.php?func=detail&aid=1509798&group_id=5470&atid=355470 .. _todos: http://trentm.com/projects/which/TODO.txt > (Not all of it, of course; there's some useful stuff there that I > *didn't* write, which ended up there because it is either *used* by > the distro (e.g. the compiler package support) or because the author > needed a channel that guaranteed open source status (e.g. world and > pynche). But Trent's which.py doesn't seem to fall in either > category.) > > --Guido > > On 3/31/07, Shane Geiger <[EMAIL PROTECTED]> wrote: >> Trent Mick has a module called which.py that might make a nice >> platform-independent replacement for python2.5/Tools/scripts/which.py. >> >> http://www.trentm.com/projects/which/ >> >> Why which.py? >> >> |which.py| is a small GNU-which replacement. It has the following features: >> >> * it is portable (Windows, Linux, Mac OS X, Un*x); >> * it understands PATHEXT and "App Paths" registration on Windows >> (i.e. it will find everything that |start| does from the command >> shell); >> * it can print all matches on the PATH; >> * it can note "near misses" on the PATH (e.g. files that match but >> may not, say, have execute permissions); and >> * it can be used as a Python module. >> >> I also would be happy to have this be a replacement for the |which.py| >> in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is >> Unix-specific and not usable as a module; and perhaps for inclusion in >> the stdlib. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
on 01.04.2007 17:23 Guido van Rossum said the following: > It's out of character for the standard library, since (regardless of > whether it's implemented in Python or part of the standard library) > it's a stand-alone utility. I don't see much use for this as a library > module. I use it as a library, because it encodes knowledge about locating executables on different platforms, especially Windows. Unixoids have which and the search is relatively straightforward. Windows searches paths in PATH and in the registry, and uses PATHEXT, so, for me, the main benefit of which.py is that it provides a which replacement on Windows that takes these quirks into account. A small use case, but a use case nevertheless. I never use which.py as a stand-alone utility as I have cygwin. (But I think it would be helpful when deploying on somebody else's Windows computer.) Of course it is your call if it fits in the stdlib or not. cheers, stefan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] str object going in Py3K
on 16.02.2006 06:59 Alex Martelli said the following: > On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote: > >> On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote: >> >>> Regarding open vs. opentext, I'm still not sure. I don't want to >>> generalize from the openbytes precedent to openstr or openunicode >>> (especially since the former is wrong in 2.x and the latter is wrong >>> in 3.0). I'm tempting to hold out for open() since it's most >>> compatible. >> If we go with two functions, I'd much rather hang them off of the file >> type object then add two new builtins. I really do think file.bytes() >> and file.text() (a.k.a. open.bytes() and open.text()) is better than >> opentext() or openbytes(). > > I agree, or, MAL's idea of bytes.open() and unicode.open() is also > good. My fondest dream is that we do NOT have an 'open' builtin > which has proven to be very error-prone when used in Windows by > newbies (as evidenced by beginner errors as seen on c.l.py, the > python-help lists, and other venues) -- defaulting 'open' to text is > errorprone, defaulting it to binary doesn't seem the greatest idea > either, principle "when in doubt, resist the temptation to guess" > strongly suggests not having 'open' as a built-in at all. (And > namemangling into openthis and openthat seems less Pythonic to me > than exploiting namespaces by making structured names, either > this.open and that.open or open.this and open.that). IOW, I entirely > agree with Barry and Marc Andre. > `open`ing a file, i.e. constructing a `file` object, always requires a path argument. In case that Py3k manages to incorporate a `Path` object, I could be more natural to have `.openbytes` and `.opentext` as methods on Path objects. But `bytes.open` and `text/unicode/str.open` looks nice too. Just for the record, stefan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
on 04.05.2006 14:57 Nick Coghlan said the following:
> Mike Orr wrote:
>> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a
>> separate PEP. It's too different to fit into PEP 355, and too big to
>> be summarized in the "Open Issues" section. Of course, one PEP will
>> be rejected if the other is approved.
>
> I agree that a competing PEP is probably the best way to track this idea.
>>> This means that path objects aren't the string representation of a
>>> path; they are a ''logical'' representation of a path. Remember why a
>>> filesystem path is called a path - because it's a way to get from one
>>> place on the filesystem to another. Paths can be relative, which means
>>> that they don't define from where to start the walk, and can be not
>>> relative, which means that they do. In the tuple representation,
>>> relative paths are simply tuples of strings, and not relative paths
>>> are tuples of strings with a first "root" element.
>
> I suggest storing the first element separately from the rest of the path. The
> reason for suggesting this is that you use 'os.sep' to separate elements in
> the normal path, but *not* to separate the first element from the rest.
I want to add that people might want to manipulate paths that are not
for the currently running OS. Therefore I think the `sep` should be an
attribute of the "root" element.
For the same reason I'd like to add two values to the following list:
> Possible values for the path's root element would then be:
>
>None ==> relative path
(uses os.sep)
+path.UNIXRELATIVE ==> uses '/'
+path.WINDOWSRELATIVE ==> uses r'\' unconditionally
>path.ROOT ==> Unix absolute path
>path.DRIVECWD ==> Windows drive relative path
>path.DRIVEROOT ==> Windows drive absolute path
>path.UNCSHARE ==> UNC path
>path.URL ==> URL path
>
> The last four would have attributes (the two Windows ones to get at the drive
> letter, the UNC one to get at the share name, and the URL one to get at the
> text of the URL).
>
> Similarly, I would separate out the extension to a distinct attribute, as it
> too uses a different separator from the normal path elements ('.' most
> places,
> but '/' on RISC OS, for example)
>
> The string representation would then be:
>
>def __str__(self):
>return (str(self.root)
>+ os.sep.join(self.path)
>+ os.extsep + self.ext)
>
>>> The advantage of using a logical representation is that you can forget
>>> about the textual representation, which can be really complex.
>
> As noted earlier - text is a great format for path related I/O. It's a lousy
> format for path manipulation.
>
>>> {{{
>>> p.normpath() -> Isn't needed - done by the constructor
>>> p.basename() -> p[-1]
>>> p.splitpath() -> (p[:-1], p[-1])
>>> p.splitunc() -> (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot))
>>> p.splitall() -> Isn't needed
>>> p.parent -> p[:-1]
>>> p.name-> p[-1]
>>> p.drive -> p[0] (if isinstance(p[0], path.Drive))
>>> p.uncshare-> p[0] (if isinstance(p[0], path.UNCRoot))
>>> }}}
>
> These same operations using separate root and path attributes:
>
> p.basename() -> p[-1]
> p.splitpath() -> (p[:-1], p[-1])
> p.splitunc() -> (p.root, p.path)
> p.splitall() -> Isn't needed
> p.parent -> p[:-1]
> p.name-> p[-1]
> p.drive -> p.root.drive (AttributeError if not drive based)
> p.uncshare-> p.root.share (AttributeError if not drive based)
>
>> That's a big drawback. PEP 355 can choose between string and
>> non-string, but this way is limited to non-string. That raises the
>> minor issue of changing the open() functions etc in the standard
>> library, and the major issue of changing them in third-party
>> libraries.
>
> It's not that big a drama, really. All you need to do is call str() on your
> path objects when you're done manipulating them. The third party libraries
> don't need to know how you created your paths, only what you ended up with.
>
> Alternatively, if the path elements are stored in separate attributes,
> there's
> nothing stopping the main object from inheriting from str or unicode the way
> the PEP 355 path object does.
>
> Either way, this object would still be far more convenient for manipulating
> paths than a string based representation that has to deal with OS-specific
> issues on every operation, rather than only during creation and conversion to
> a string. The path objects would also serve as an OS-independent
> representation of filesystem paths.
>
> In fact, I'd leave most of the low-level API's working only on strings - the
> only one I'd change to accept path objects directly is open() (which would be
> fairly easy, as that's a factory function now).
>
>>> This means that paths starting with a drive letter alone
>>> (!UnrootedDrive instance, in my module) and paths starting with a
>>> backslash alone (the CURROOT object, in my module) are no
Re: [Python-Dev] Alternative path suggestion
on 04.05.2006 16:18 Paul Moore said the following:
> On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
>> and 'extsep' keyword arguments to the constructor, and provided the
>> appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a
>> shortcut to avoid specifying the separators explicitly).
>>
>> That way the main class can avoid being complicated by the relatively rare
>> need to operate on another platform's paths, while still supporting the
>> ability.
>
> You ought to have predefined classes for the standard OSes. Expecting
> people to know the values for sep and extsep seems unhelpful.
>
I assume that having subclasses (at least for the different os
filesystem paths) is not necessary.
The sep and extsep that needs to be used is determined by the root of
the path.
The root, I suppose, is set when constructing the path from a string.
The ambiguous cases are relative paths and `p = path()`.
(Also think of the proposed URL root which normally would mandate '/' as
sep. Actually, the format depends on the 'scheme' part of the URL...)
On the output side ( `str(pathinstance)` ) the format is determined by
the root.
At least if you ignore people who want to have
C:/this/style/of/acceptable/windows/path
When constructing a relative path, I suggest creating a os dependent one
(root==None) by default, even if you use::
p = path('./unix/relative/style')
on Windows.
Daring people can later use::
p.root = path.WINDOWSRELATIVE# or
p.root = path.UNIXRELATIVE
if they need to.
stefan
___
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/archive%40mail-archive.com
Re: [Python-Dev] properties and block statement
on 18.10.2005 19:17 Antoine Pitrou said the following:
>>What would this mythical block statement look like that would make
>>properties easier to write than the above late-binding or the subclass
>>Property recipe?
>
> I suppose something like:
>
> class C(object):
> x = prop:
> """ Yay for property x! """
> def __get__(self):
> return self._x
> def __set__(self, value):
> self._x = x
>
> and then:
>
> def prop(@block):
> return property(
> fget=block.get("__get__"),
> fset=block.get("__set__"),
> fdel=block.get("__delete__"),
> doc=block.get("__doc__", ""),
> )
>
> (where "@bargs" would be the syntax to refer to block args as a dict,
> the same way "**kargs" already exist)
>
I think there is no need for a special @syntax for this to work.
I suppose it would be possible to allow a trailing block after any
function invocation, with the effect of creating a new namespace that
gets treated as containing keyword arguments.
No additional function needed for the property example::
class C(object):
x = property():
doc = """ Yay for property x! """
def fget(self):
return self._x
def fset(self, value):
self._x = x
(This does not help with the problem of overridability though...)
A drawback is that such a "keyword block" would only be possible for the
last function invocation of a statement.
Although the block could also be inside the method invocation
parentheses? I do not think that this is a pretty sight but I'll spell
it out anyways ;-) ::
class C(object):
x = property(:
doc = """ Yay for property x! """
def fget(self):
return self._x
def fset(self, value):
self._x = x
)
--stefan
___
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/archive%40mail-archive.com
Re: [Python-Dev] The path module PEP
on 26.01.2006 14:15 Paul Moore said the following:
[snip]
>
> Also note that my example Path("C:", "Windows", "System32") above is
> an *absolute* path on Windows. But a relative (albeit stupidly-named
> :-)) path on Unix. How would that be handled?
wrong, Path("C:", "Windows", "System32") is a relative path on windows.
see below.
> Not that os.path gets it perfect:
>
> Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
import os
os.path.join("C:", "Windows", "System32")
> 'C:Windows\\System32'
os.path.join(".", os.path.join("C:", "Windows", "System32"))
> '.\\C:Windows\\System32'
>
this is misleading. observe::
In [1]: import os
In [2]: os.path.join(".", os.path.join("C:", "Windows", "System32"))
Out[2]: '.\\C:Windows\\System32'
but::
In [3]: os.path.join(".", os.path.join("C:\\", "Windows", "System32"))
Out[3]: 'C:\\Windows\\System32'
The second example uses an absolute path as second argument, and as
os.path.join should do, the first argument is discarded.
The first case is arguably a bug, since, on windows, C:Windows\System32
is a path relative to the *current directory on disk C:*
If the cwd on C: would be C:\temp then C:Windows\System32 would point to
C:\temp\Windows\System32
The problem is that Windows has a cwd per partition...
(I cannot even guess why ;-)
For the sake of illustration, the following is a WinXP cmd session::
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\temp>d:
D:\>cd HOME
D:\HOME>c:
C:\temp>d:
D:\HOME>c:
C:\temp>cd d:bin
C:\temp>d:
D:\HOME\bin>
[snip]
>
> Arguably, Path objects should always maintain an absolute path - there
> should be no such thing as a relative Path. So you would have
you realise that one might need and/or want to represent a relative path?
___
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/archive%40mail-archive.com
Re: [Python-Dev] The path module PEP
on 26.01.2006 16:34 Aaron Bingham said the following: > Stefan Rank wrote: >> on 26.01.2006 14:15 Paul Moore said the following: >> [snip] >> >>> Arguably, Path objects should always maintain an absolute path - there >>> should be no such thing as a relative Path. >>> >> you realise that one might need and/or want to represent a relative path? >> > Of course, but it seems to me a relative path is a different type from > an absolute path, in the same way that a timedelta is different from a > datetime. > > For example: > > * You can't open a relative path without reference to some absolute > path (possibly the cwd). > * You can't join two absolute paths, but you can join a relative path > to another relative path, or to an absolute path. I think the datetime/timedelta analogy is not bad: A datetime is actually also a time delta - relative to some given start-time, internally this is normally the "epoch". For human-readable representations it is the birth of your chosen deity, or the creation of the universe, ... The start time for datetime is implicit. Python has chosen some absolute reference. For paths that absolute reference (the root) is very much context dependent (platform dependent). You *can* open a relative path - because processes always have an implicit cwd as part of their context. But you might also want to represent paths that are relative on another host than the one your program is running on. I don't think it makes sense to design a Path class that captures the abstract concept of a path - because of the semantic differences between unix paths, windows paths, URL paths, ... I see the Path object as a special kind of string, that has helpful methods for relating it to the workings of filesystems in general and the local filesystem in particular. But it is still just an ordinary string that happens to be used as a special kind of address. I try to separate the concept of the 'object in the filesystem' (which is the domain of Python's file objects) from the 'hierarchical address to an object' (which is what the Path objects make easier). (Java has these two conflated in one.) So, to get to the point, a `file` is a thing that should always have an absolute path. (and it does. it should probably grow a .path attribute in addition to .name ? This could return None for files without paths.) A Path should be able to contain absolute, relative, valid, as well as invalid (on a given OS) paths. In case that future systems manage to reduce the importance of the legacy crutch that is the hierarchical filesystem ;-) we might get query-like addresses: '/tmp/[author=me;type=text/html]' and Path might grow to deal with it. Sorry I digress. +1 on Path as an enhanced string that bundles file-system-address related methods. stefan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] The path module PEP
on 27.01.2006 11:16 Paul Moore said the following: > [...] >>> Arguably, Path objects should always maintain an absolute path - there >>> should be no such thing as a relative Path. So you would have >> you realise that one might need and/or want to represent a relative path? > > Absolutely. But not a Path (see distinction above). > > Aaron Bingham's analogy with time/timedelta applies well here. > Relative paths, like relative times, have their own special semantics, > which deserve to be addressed in a separate class. > > You argue that time is "merely" a timedelta with a fixed start point. > I'd disagree - the key point with timedeltas is that they need careful > handling (DST issues, for example) _depending upon precisely what they > are added to_ - these issues are avoided by the time type exactly > because it has a constant base. In exactly the same way, absolute > paths have simpler semantics precisely because they are absolute. > > Paul. I see your point. I guess there are two options: - `Path` as an enhanced string type that bundles methods related to file system addressing - `Path`s that accurately reflect the possible (abstract) paths. There would be a Path and a PathDelta (with appropriate combining semantics), and probably a UnixPath, a WindowsPath, an URLPath maybe. And there need to be appropriate methods for combining them with/creating them from strings. I actually think the latter would be very neat and somewhere else in this thread someone talks about his `Tree` - `Path` - `File` classes with specialised subclasses. The first option, however, has the benefit of simplicity and there is a working implementation. Well - I'm not the one to decide. And I think anything that bundles path related stuff (using a little object-orientation) and cleans up the standard library is a step forward. cheers, s ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
on 03.02.2006 00:16 Delaney, Timothy (Tim) said the following: > Andrew Koenig wrote: >>> I definately agree with the 0c664 octal literal. Seems rather more >>> intuitive. >> I still prefer 8r664. > The more I look at this, the worse it gets. Something beginning with > zero (like 0xFF, 0c664) immediately stands out as "unusual". Something > beginning with any other digit doesn't. Let me throw something into the arena :-) I know there should only be one way to do it, but what about requiring a leading 0 for any 'special' number format, and then allow:: 0x1AFFE and:: 016r1AFFE 02r010001000101001 08r1234567 and maybe have 0b be a synonym of 02r, and some other nice character (o/c) for octals. For backwards compatibility you could even allow classic octal literals, though I think it would be better to have a Syntax Error for any literal starting with 0 but missing a radix code. cheers ___ 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/archive%40mail-archive.com
