On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
Robert Brewer writes:
Python 3.1 was released June 27th, 2009. We're coming up faster on the
two-year period than we seem to be on a revised WSGI spec. Maybe we
should shoot for a bytes of a known encoding
handle like that, but if something is syntactically acceptable in
both Python 2 and 3 then it's a lot easier to apply simple conditionals
around semantics. This would remove the need, for example, for people to
use sys.exc_info() to avoid using except Exception as e.
--
Ian Bicking | http
with Python 2.
--
Ian Bicking | http://blog.ianbicking.org
___
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
is a little annoying, but a delayed error doesn't lead to mojibake.
Mojibake is caused by allowing bytes and text to intermix, and the
polymorphic functions as proposed don't add new dangers in that regard.
--
Ian Bicking | http://blog.ianbicking.org
(as well as
other small errata like the size hint) doesn't detract from PEP 444 at all,
IMHO.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
to test compliance. If you want your application to output
strings rather than bytes, you can always use a decorator to do that. (And
a sample one could be provided in wsgiref.)
I agree allowing both is not ideal.
--
Ian Bicking | http://blog.ianbicking.org
view -- unicode
viewing bytes. I'm not sure I could keep two views straight. I *think*
Antoine is describing two possible canonical data types (unicode or bytes)
and two views. That sounds hard.
--
Ian Bicking | http://blog.ianbicking.org
___
Python
and the application can determine
what kind of plugin it is. But having described this, it actually doesn't
seem like a useful thing to generalize.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http
that into the tools, but
it's a lot easier to make the tools permissive and build these distinctions
into social structures.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
background (e.g., to help with
installing a monitor on the server).
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
then ship the most recent stable release of
IDLE.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
text support from any of these functions, only that we allow bytes.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
functions, they aren't
objects that should be passed around much. So you can easily identify and
quickly detect if you use unsupported operations on those text-like
objects. (This is all a very different use case from bytes+encoding, I
think)
--
Ian Bicking | http://blog.ianbicking.org
On Fri, Jun 25, 2010 at 11:30 AM, Stephen J. Turnbull step...@xemacs.orgwrote:
Ian Bicking writes:
I'm proposing these specials would be used in polymorphic functions,
like
the functions in urllib.parse. I would not personally use them in my
own
code (unless of course I was writing
it as an optimized str representation that is
otherwise semantically equivalent). A String ABC would formalize these
things.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
the Python 2 craziness.
--
Ian Bicking | http://blog.ianbicking.org
___
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
bytes to describe HTTP (
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54#page-13),
though this annoyed many people.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
= quote_unsafe_bytes(fragment.encode('UTF-8', errors))
return urlunsplit_bytes((scheme, netloc, path, query, fragment))
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
to
want to take the same approach, sticking with unencoded data in nearly all
situations.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
.
--
Ian Bicking | http://blog.ianbicking.org
___
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
. XML is someplace where you
might load a bunch of data but only touch a little bit of it, and the amount
of data is frequently large enough that the efficiencies are important.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
with the standard library, so continuing to release
argparse under the name argparse will cause problems. I would hate to see
release complications or confusions keep argparse from seeing future
development.
--
Ian Bicking | http://blog.ianbicking.org
, for simplicity, I thought it should be relative to the
directory where the record file is (lots of extraneous ../, but the most
obvious meaning of a relative filename).
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev
there will be ../../../bin/rst2html.py that
will still be under the (virtual) sys.prefix, and the whole bundle can be
usefully moved around.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
are developed there's a clear way to get started with them, without
prematurely baking anything in to Python.
--
Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking
___
Python-Dev mailing list
Python-Dev@python.org
http
is; maybe this is
resolved? If distributing bytecode required renaming pyc files to .py
as Glenn suggested that would resolve the problem quite nicely from my
perspective. (Frankly I find the whole use case for distributing
bytecodes a bit specious, but whatever.)
--
Ian Bicking | http
is in the #! line.
I'm at PyCon and would be interested in debating / sprinting on this if
there's interest.
Yeah, if you see me around, please catch me!
--
Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking
___
Python-Dev
On Fri, Feb 19, 2010 at 10:39 PM, Glenn Linderman
v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com
wrote:
On approximately 2/19/2010 1:18 PM, came the following characters from the
keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work
, or a
checkout (to test just one new piece of code).
I'm not sure how this should best work on Windows (without symlinks, and
where things generally work differently), but I would hope if this idea is
more visible that someone more opinionated than I would propose the
appropriate analog on Windows.
--
Ian
actually suggest returning a unicode subclass that won't ever emit
UnicodeEncodeError when it is converted to a str or bytes. Correctness at
that stage is not as important as not losing the exception.
So... a few suggestions.
--
Ian Bicking | http://blog.ianbicking.org
(and then implement a
pythonz command that could do useful stuff) then that might work. Though
generally #! is so broken that it's really hard to come up with a reasonable
option for these cases.
--
Ian Bicking | http://blog.ianbicking.org
___
Python
On Tue, Jan 26, 2010 at 2:44 PM, Glyph Lefkowitz gl...@twistedmatrix.comwrote:
On Jan 26, 2010, at 3:20 PM, Ian Bicking wrote:
Sadly you can't then do:
chmod +x mz.py
./mz.py
Unless I missed some subtlety earlier in the conversation, yes you can :).
You are entirely correct; I
itself the canonical source, so to fix bugs you have to look at
the installed source and trace it back to the bug in the original source.
I suspect a reasonable workflow might be possible with hg and maybe patch
queues, but I don't feel familiar enough with those tools to map that out.
--
Ian Bicking
development
that much more complicated and much less fun, with no concrete
benefits. Which is a terribly crotchety of me. Sorry.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
___
Python-Dev mailing list
Python-Dev
it. The proposed language
seems to imply it is wrong to keep using optparse, which I don't think
is the case. And people can pick up on this kind of language and get
all excitable about it.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard
steven.beth...@gmail.com wrote:
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking i...@colorstudy.com wrote:
On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
steven.beth...@gmail.com wrote:
So there wasn't really any more feedback on the last post
is better
than the other, but at least one of those should be done.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
ELLIPSIS but able also be more flexible
than currently possible, like:
throw_an_exception()
Traceback (most recent call last):
...
DesiredException: [[2.6 error message | 2.7 error message]]
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org/civichacker
On Wed, Dec 9, 2009 at 5:47 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/12/9 Lennart Regebro lrege...@jarn.com:
On Wed, Dec 9, 2009 at 18:45, Ian Bicking i...@colorstudy.com wrote:
It's about time doctest got another run of development anyway. I can
imagine a couple features that might
it, easy_install broke, and a
compromise was to keep /pypi/ the way it was (but not /pypi).
Probably this could be removed, as the /simple/ index is already
case-insensitive, so easy_install shouldn't have to hit /pypi/ at all.
--
Ian Bicking | http://blog.ianbicking.org |
http://topplabs.org
some more
features in those tools, but I'm open to that). But specific
discussion of this would probably be more appropriate on
distutils-sig.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
___
Python-Dev mailing list
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/10/9 Antoine Pitrou solip...@pitrou.net:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very
or desirable.
Nobody is trying that with deb/rpm either.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
on
easy_install). I don't think the philosophical differences are that
great, and that it's more a matter of history -- because the code is
written, there's not much incentive for buildout to remove that code
and rely on other libraries (virtualenv and pip).
--
Ian Bicking | http://blog.ianbicking.org
Ian Bicking wrote:
Phillip J. Eby wrote:
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
I'd like to include paste.lint with that as well (as wsgiref.lint or
whatever). Since the last discussion I enumerated in the docstring all
the checks it does. There's still some outstanding issues
Phillip J. Eby wrote:
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
I'd like to include paste.lint with that as well (as wsgiref.lint or
whatever). Since the last discussion I enumerated in the docstring all
the checks it does. There's still some outstanding issues, mostly where
I'm
though, just some questions
about the particulars of the server. I think there were at least a
couple small suggestions for the wsgiref server; in particular maybe a
slight refactoring to make it easier to use with https.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
of checks that should take place (most related to /'s),
and the not found response should be configurable (probably as an
application that can be passed in as an argument). But that's most of
what it should do.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
is pretty easy to do at the same time, and in my
experience can be useful to do at the same time, but I don't really care
if that feature goes in.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev
to .default.
Prefix matching wouldn't show off anything else in wsgiref, because
there's nothing else to use; paste.urlmap doesn't use any other part of
Paste either (except one unimportant exception) because there's just no
need.
--
Ian Bicking / [EMAIL PROTECTED] / http
Phillip J. Eby wrote:
At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
I don't see why not to use prefix matching. It is more consistent with
the handling of the default application ('', instead of a method that
needs to be overridden), and more general, and the algorithm is only
barely
Phillip J. Eby wrote:
At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
It will still be only a couple lines less than prefix matching.
That's beside the point. Prefix matching is inherently a more complex
concept, and more likely to be confusing, without introducing much in
the way of new
a message like
You might be missing an __init__.py file.
+1. It's not that putting an __init__.py file in is hard, it's that
people have a hard time realizing when they've forgotten to do it.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
Paul Moore wrote:
And no, I don't want to install the 2 versions side-by-side. Ian
Bicking complained recently about the uncertainty of multiple
directories on sys.path meaning you can't be sure which version of a
module you get. Well, having 2 versions of a module installed and
knowing
own systems.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
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
it the other way. Sorry. Please ignore.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
he wanted documented.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
using older constructs (like a plain
__call__(**kw)) to keep that in addition to supporting this new construct.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
myparser:
make Option verbose:
short = '-v'
help = ...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
in ElementDict():
...
Maybe Element.__make_dict__ could be ElementDict. This doesn't feel
that unclean if you are also using Element.__make__ instead of
Element.__call__; though there is a hidden cleverness factor (maybe in a
bad way).
--
Ian Bicking / [EMAIL PROTECTED
assert bag.count(0) == 0
assert 3 in bag
# etc...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
the constructs very different.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
vague).
partial would make just as much sense in functools as in functional.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
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
Raymond Hettinger wrote:
[Ian Bicking]
The question then is what the API should look like for such an object --
an ordered, multi-value dictionary.
May I suggest that multidict begin it's life as a cookbook recipe so that its
API can mature.
There's already quite a few recipes out
a feature.
I actually thought it was only defined for interactive sessions, but a
brief test shows I was wrong. It doesn't bother me, but it does make me
think that exit(1) should exit with a code of one.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
where the interpreter would abruptly exit.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
$
Or:
if raw_input('quit?') == 'yes':
... quit
will that work? Should it? Functions are pretty predictable in
comparison to these other options. So, at least to me, quit() == KISS
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
dictionary -- the
normalized key is never actually exposed anywhere. I didn't follow the
defaultdict thing through to the end, so I didn't catch what the
constructor was going to look like for that; but I assume those choices
will apply here as well.
--
Ian Bicking | [EMAIL PROTECTED] | http
of the code being run.
I think you are reading too much into it. If the functions exist, they
should be useful. That's all I see in Michael's suggestion.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
an operator? I.e.:
# Required assignment to declare?:
chunk = None
while chunk := f.read(1000):
...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
threadsafety is hard to test in
this case. (If anyone is interested in trying it, I can email what I have.)
Note that multidict -- among other possible concrete collection patterns
(like Bag, OrderedDict, or others) -- can be readily implemented with
threading guarantees.
--
Ian Bicking
nice
properties -- inclusion is done with __contains__ (with dicts it
probably has to be done with get), you can't accidentally go below zero,
the methods express intent, and presumably it will implement only a
meaningful set of methods.
--
Ian Bicking / [EMAIL PROTECTED] / http
harder than I
thought at first -- I think the actual cases I'm using work, since they
use simple keys (ints, strings), but yeah, thread guarantees are too
difficult to handle in general. Damn threads.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
-encompassing, they just do one kind of container well.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
collections, normalized keys can be useful. (Though
notably the wsgiref Headers object does not have normalized keys, but
instead does case-insensitive comparisons.) I don't know where
dict-of-dict best fits in here.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
quo is
not really that bad.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
I really don't like that defaultdict (or a dict extension) means that
x[not_found] will have noticeable side effects. This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple values for each key, and in the process breaking an important
quality of
Guido van Rossum wrote:
On 2/17/06, Ian Bicking [EMAIL PROTECTED] wrote:
I really don't like that defaultdict (or a dict extension) means that
x[not_found] will have noticeable side effects. This all seems to be a
roundabout way to address one important use case of a dictionary with
multiple
jumping out at
me at the moment. Of course, it is not a Pythonic argument to say that
an existing method should be overridden, or functionality made nameless
simply because we can't think of a name (looking to anonymous functions
of course ;)
--
Ian Bicking / [EMAIL PROTECTED] / http
it applies, but I see no problem at all with a new
method on dictionaries that calls on_missing.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
transformations, applicable to both unicode and byte objects.
Let's not throw the baby out with the bath water.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
lazily.
It is lazily incarnated for multidict, because there is no *noticeable*
side effect -- if there is any internal side effects that is an
implementation detail. However for default_factory=list, the result of
.keys(), .has_key(), and .items() changes when you do d[some_key].
--
Ian
.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
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
argue lists of ints is data too (but an
arbitrary list definitely isn't data). On the outer end of data might
be an ElementTree structure (but that's getting fishy). An open file
object is not data. A tuple probably isn't data.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
Martin v. Löwis wrote:
Ian Bicking wrote:
That str.encode(unicode_encoding) implicitly decodes strings seems like
a flaw in the unicode encodings, quite seperate from the existance of
str.encode. I for one really like s.encode('zlib').encode('base64') --
and if the zlib encoding raised
Alex Martelli wrote:
Maybe we could fix that by having property(getfunc) use
getfunc.__doc__ as the __doc__ of the resulting property object
(easily overridable in more normal property usage by the doc=
argument, which, I feel, should almost invariably be there).
+1
--
Ian Bicking
') == 'a b'? That's not what you meant, but
nevertheless that would be an excellent encoding ;)
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
, or section naming conventions.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
extending and working around the configuration
interface.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
compatibility, but I think if
it was introduced into the standard library that might be an opportunity
to trim the API back again before it enters the long-term API freeze
that the standard library demands.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
) to accept Path objects
may resolve issues with a substantial portion of code. But any code
that does a typecheck on arguments will be broken -- which in the case
of paths is quite common since many functions take both filename and
file object arguments.
--
Ian Bicking / [EMAIL PROTECTED
a little confused by the glob arguments (if
the glob contains '/'), now that I really think about them.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
John J Lee wrote:
On Tue, 24 Jan 2006, Ian Bicking wrote:
[...]
Losing .open() would make it much harder for anyone wanting to write,
say, a URI library that implements the Path API.
[...]
Why? Could you expand a bit?
What's wrong with urlopen(filesystem_path_instance) ?
My example
as Python?) PEP 8 encourages
following naming precedence. While I don't see a need to match every
existing function with a method, to the degree they do match I see no
reason why we shouldn't keep the names. And I see reasons why the names
shouldn't be changed.
--
Ian Bicking / [EMAIL
,
and os.path.join less, but I'm guessing the majority of users are more
like me.
That's not necessarily a justification of / for paths, but at least this
use for / wouldn't be obscure or mysterious after you get a little
experience seeing code that uses it.
--
Ian Bicking / [EMAIL PROTECTED] / http
Tony Meyer wrote:
[Ian Bicking]
If it were possible to use .join() for joining paths, I think I
wouldn't mind so much. But reusing a string method for something
very different seems like a bad idea. So we're left with .joinpath
(). Still better than os.path.join() I guess, but only
is sometimes worse than usually harmful.
+ seems completely innocuous, though:
ext = '.jpg'
name = fields['name']
image = Path('/images') / name + ext
It doesn't really matter what order it happens in there. Assuming
concatenation results in a new Path object, not a str.
--
Ian
Barry Warsaw wrote:
On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote:
Paths are strings, that's in the PEP.
As an aside, I think it should be specified what (if any) string methods
won't be inherited by Path (or will be specifically disabled by making
them throw some exception). I
something novel like urljoin.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
1 - 100 of 130 matches
Mail list logo
