On Sun, Jan 9, 2011 at 1:47 AM, Stephen J. Turnbull wrote:
> 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" type first.
uiring some annotation of code to make it run,
but less invasive than translating code itself. There's still major things
you can't 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 sema
and distributed with
Python, but with the current plan that will never happen 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
ted with arbitrary combinations of strings and
> bytes in order 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 agre
sense, making WSGI 1 sensible for Python 3 (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.pytho
;t work (e.g.,
urlparse.urljoin(text_url, urlparse.urlsplit(byte_url).path). Delaying the
error 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 f
you don't know
about, or don't want to know about, or maybe just don't fit into the unicode
model (like a string with two character sets).
Note that WebOb does not have two views, it has only one view -- unicode
viewing bytes. I'm n
ply refer to an object 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 mail
review than
changing stuff in the core. We could try to build 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-D
am of people managing PyPI could benefit from the
addition of someone with more of a sysadmin background (e.g., to help with
installing a monitor on the server).
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@pytho
ity of changes and
releases. Python releases would 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
U
got overly worried about that.
>
It wasn't my profiling, but I seem to recall that Fredrik Lundh specifically
benchmarked ElementTree with all-unicode and sometimes-ascii-bytes, and
found that using Python 2 strs in some cases provided notable advantages. I
know Stefan copied
On Fri, Jun 25, 2010 at 11:30 AM, Stephen J. Turnbull wrote:
> 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 (un
m in my own
code (unless of course I was writing my own polymorphic functions).
This also makes it less important that the objects be a full stand-in for
text, as their use should be isolated to specific functions, they aren't
objects that should be passed around much. So you
treat URLs as bytes,
and that code will be incompatible with URLs as text? No one is arguing we
remove text support from any of these functions, only that we allow bytes.
--
Ian Bicking | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-D
is new special kind of string, if you call:
urlunsplit((b'http', b'example.com', b'/foo', 'bar=baz', b''))
You'd end up constructing the URL b'http://example.com/foo' and then
running:
url = url + special('?') + query
An
there are some
constraints with the current str/bytes implementations. Reading PEP 3003
I'm not clear if such changes are part of the moratorium? They seem like
they would be (sadly), but it doesn't seem clearly noted.
I think there's a *different* use case for things like
bytes-i
path = quote_unsafe_bytes(path.encode('UTF-8', errors))
query = quote_unsafe_bytes(query.encode(page_encoding, errors))
fragment = quote_unsafe_bytes(fragment.encode('UTF-8', errors))
return urlunsplit_bytes((scheme, netloc, path, query, fragment))
--
Ian Bicking | http://blog
specifically. Or another example, making a GET request
really means sending the bytes \x47\x45\x54 and there is no other set of
bytes that has that meaning. The WebSockets specification for instance
defines things like "colon":
http://tools.ietf.org/html/draft-hixie-thewebsocketprot
This is a place where
bytes+encoding might also have some benefit. 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
ring that is bytes+encoding. I think PJE brought up a problem with a
couple coercion aspects.
--
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
occasionally to
*display* some data in a more friendly way. But it's only display, and
errors just make it revert to the old encoded display.
Similarly I'd expect (from experience) that a programmer using Python to
want to take the same approach, sticking with unencoded data in nearly all
situa
e unittest2. I believe there is strong disfavor with releasing
packages that overlap 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.
ver had a usecase for libdir-relativity
> personally.)
Yes, in a virtualenv environment 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
__
s is why, 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
Py
could write "python -m boostrap
Setuptools --user" -- entirely based on some well-known URL baked into
bootstrap.py, where the URL is independent of any other service (and so is
least likely to cause future problems or ambiguities).
An advantage to this kind of bootstrapper is that as fu
_install but
not pip -- usually this is an oversight on the part of the person
doing the packaging, but they just never noticed.
--
Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking
___
Python-Dev mailing list
Python-Dev@pytho
t the current proposal 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.)
precedence over earlier ones.
> * What should sys.interpreter be? Explicit is better than implicit:
> the first pythonv to run also adds a --interpreter to
> the front of the command-line. Or they could all add it and
> python only uses the last one. This is one
On Fri, Feb 19, 2010 at 10:39 PM, Glenn Linderman
> 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 on
nvironments that contain for instance an actual application, 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 opinion
(mostly at a console) the bottom is easiest.
Oh, and you even should consider: will you get a unicode error on output?
I'd actually suggest returning a unicode subclass that won't ever emit
UnicodeEncodeError when it is converted to a str or bytes. Correctness a
On Tue, Jan 26, 2010 at 2:44 PM, Glyph Lefkowitz wrote:
>
> 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 :).
>
Yo
about it but will still unpack the file, but
it won't be runnable as Python won't recognize it as a zip anymore. Now if
you could, say, put in "#!/usr/bin/env pythonz" (and then implement a
pythonz command that could do useful stuff)
out is put on the path. I guess I could have something that
automatically builds the code on every edit, and that's not
infeasible. It's just not fun. So long as I have to support Python 2
(which is like forever) then adding Python 3 only makes development
that much more complicated and
the norm for most libraries, I think).
Also, running 2to3 on installation is kind of annoying, as you get source
that isn't 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 m
p' (0x70) at index 1 -- that's simply a
bad error message. Giving a proper error message takes about as much
code as making %prog work. I don't feel strongly that one is better
than the other, but at least one of those should be done.
--
Ian Bicking | http://blog.ianbicking.o
On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard
wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PE
y are successfully
using it there's no reason to stop using 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 excitab
On Wed, Dec 9, 2009 at 5:47 PM, Paul Moore wrote:
> 2009/12/9 Lennart Regebro :
>> On Wed, Dec 9, 2009 at 18:45, Ian Bicking wrote:
>>> It's about time doctest got another run of development anyway. I can
>>> imagine a couple features that might help:
>>&g
de (avoiding throw_an_exception() from being
called twice).
* Or, something more explicit than 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
tive searches). Someone changed 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 | h
en it can be queried. I don't think querying
the Windows system package management would be necessary or desirable.
Nobody is trying that with deb/rpm either.
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
___
Pytho
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore wrote:
> 2009/10/9 Antoine Pitrou :
>> Ian Bicking colorstudy.com> writes:
>>>
>>> Someone mentioned that easy_install provided some things pip didn't;
>>> outside of multi-versioned installs (which I'm n
uot;funny" and "flexible" way,
> Control!
Sure; I'm just advocating that buildout more explicitly use some of
the functionality of virtualenv/pip (which may require some more
features in those tools, but I'm open to t
ration. If virtualenv had existed before buildout
began development, probably things would have gone this way. I think
it would make the environment more pleasant for buildout users. Also
I wish it used pip instead of its own installation procedure (based on
easy_install). I don't th
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
&
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 o
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 introdu
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
default
application handling in particular means that AppMap isn't really useful
without subclassing or assigning 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 e
ore specific.
URLMap's dictionary interface isn't that useful either.
Another feature that the example in my other email doesn't have is /
handling, specifically redirecting /something-that-matches to
/something-that-matches/ (something Apache's Ali
tive. I've seen cases where
other people have done the same prefix dispatching in Python *without*
matching the interface of anybody else's code or environment; that's the
sort of thing a reference implementation is meant to keep people from doing.
--
Ia
return app(environ, start_response)
start_response('404 Not Found', [('Content-type', 'text/html')])
return ['Not Found']
There's a bunch of checks that should take place (most related to /'s),
and
ebserver in wsgiref ought
> to be but nothing like the flamefest that setuptools caused (no
> comments please).
No one disagreed with the basic premise though, just some questions
about the particulars of the server. I think there were at least a
couple small suggestions for the wsgiref
f there is then append 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 / [EMAI
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 ve
sn't clear to me what exactly 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.
going back towards a calmer and more constructive discussion and I
pushed 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.o
the
tools to build that kind of facility, and egg-based installations
provide the sufficient metadata to report on what has been built. So I
think it is a step in the right direction. Integrating packages from a
wide variety of sources is hard.
--
Ian Bicking / [EMAIL PROTECTED] / ht
oo; even though Phillip has fixed the traceback
problems for 2.5 I personally just prefer files I can view in other
tools as well (my text editor doesn't like zip files, for instance). I
typically make this change in distutils.cfg for my own systems.
--
Ian Bicking / [EMAIL
they know something you don't about distribution?
ElementTree would be among those egg files, so you should also consider
how many people *haven't* asked you about problems related to the
installation process.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_
y. So __make__ would be nicer. Personally this
would also let people 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
_
ry will have a whole lot; "make" is
really only useful when frameworks are written to use it, and there's
just not a lot of framework in the standard library. Maybe:
make OptionParser myparser:
make Option verbose:
short = '-v'
help = &qu
dies to be executed in
> (3) It adds some degree of coupling between the mapping type and the
> callable. For the example above, I expect I'd have to do something
> like::
>
> make Element html in ElementDict():
> make Element head in ElementDict():
>
> d[item] += 1
> return dict(d)
Or:
import collections
bag = collections.Bag([1, 2, 3, 2, 1])
assert bag.count(1) == 2
assert bag.count(0) == 0
assert 3 in bag
# etc...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
;) Anytime I've done thought experiments
about using class decorators, the results is very hard to read. That
classes are inherently declarative and open, while functions are
imperative and closed, makes the constructs very different.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ia
r.
memoize seems to fit into functools fairly well, though deprecated not
so much. functools is similarly named to itertools, another module that
is kind of vague in scope (though functools is much more vague).
partial would make just as much sense in functools as in functional.
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 m
n whatever order you want.
--
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/
e other existing ways to exit). OTOH, maybe that's 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 / [
:
>>> quit = False
>>> while not quit: ...
>>> quit
$
Or:
>>> if raw_input('quit?') == 'yes':
... quit
will that work? Should it? Functions are pretty predictable in
comparison to these other options. So, a
t didn't require a call had some scary corner case
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/
:
del self.data[self.keyfunc(key)]
def keys(self):
return [v[0] for v in self.data.values()]
I definitely like this more than a key-normalizing dictionary -- the
normalized key is never actually exposed anywhere. I didn't follow the
defaultdict thing through
orrect. The "anything" class can be viewed
> as
> either a sequence or a mapping.
>
> In this and other posts, you seem to be focusing your design around notions
> of
> strong typing and mandatory interfaces. I would suggest that that approach
writing "x := x + y".
By rebinding operator, does that mean it is actually an operator? I.e.:
# Required assignment to declare?:
chunk = None
while chunk := f.read(1000):
...
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
s. But yeah, it's 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
ike:
dd.count(item)
No collections.Bag exists, but of course one should. It has 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
, OrderedDict, or others) -- can be readily implemented with
threading guarantees.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
#x27;t there anyone else who sees the various dict-like objects being
passed around as recipes, and thinks that maybe that's a sign they
should go in the stdlib? The best of those recipes aren't
all-encompassing, they just do one kind of container well.
--
Ian Bicking | [EMAIL
is notable. But it's not going to be extended indefinitely, so
that's just a theoretical problem.
> What about
>
> "http://www.python.org".decode("URL")
you mean 'a%20b'.decode('url') == 'a b'? That's not what you me
two ways to handle thread safety, both of which
are broken:
1) d[key] gets the GIL, and thus while default_factory is being called
the GIL is locked
2) d[key] doesn't get the GIL and so d[key].append(1) may not actually
lead to 1 being in d[key] if another thread is appending something to
t
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
--
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('
t about the
return types -- the Python type is not what we generally rely on,
though. In this case they are all "data". Unicode and bytes are both
data, and you could probably argue lists of ints is data too (but an
arbitrary list definitely isn't data). On the outer end of
and one can just hope that no one will try to use this feature and will
instead stick with the try:except KeyError: technique.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://m
fects 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 Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev mailing list
ncoding raised an error when it was passed a unicode
object (instead of implicitly encoding the string with the ascii
encoding) that would be fine.
The pipe-like nature of .encode and .decode works very nicely for
certain transformations, applicable to both unicode and byte objects.
Let'
ng *only* applies to the overriding of
__getitem__, not the addition of any new method. I think multidict is
better for the places 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.ian
x27;t the best name, but another name isn't 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 ;)
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 impo
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 g
dy works! But only if you want a read-only property. Which is
actually about 50%+ of the properties I create. So the status quo is
not really that bad.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
___
Python-Dev
ey:value, multi-value
ordered-dict: ordered, key:value, single-value
ordered-multi-dict: ordered, key:value, single-value
For all key:value collections, normalized keys can be useful. (Though
notably the wsgiref Headers object does not have normalized keys, but
instead does case-insensitive c
has too many
>>features, like nested sections. And it seems like maybe the API can be
>>
>
> I personally think nested sections are very useful and would be sad to
> not see them included. Grouping additional configuration options as a
> sub-section can be *very* handy.
e the API can be
reduced in size with a little high-level refactoring -- APIs generally
grow over time so as to preserve backward 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
n work with just the
parser, without crudely 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/l
ing open() and all the
functions that Path replaces (e.g., os.path.join) 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 filenam
does).
I assume it would be be the latter, and urljoin would be a different
method, maybe something novel like "urljoin".
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
h
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 specifi
1 - 100 of 146 matches
Mail list logo
