2009/6/20 "Martin v. Löwis" :
>> I‘d really like to get this stuff in. The performance gains allowing
>> http1.1 and gzip for xmlrpc are quite significant.
>
> I think you really need to get Fredrik Lundh to comment on it. If he
> can't predict when he'l
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> Fredrik Lundh wrote:
>>> I think you really need to get Fredrik Lundh to comment on it. If he
>>> can't predict when he'll be able to review the changes, maybe he can
>>> accept releasin
On Sat, Jun 20, 2009 at 6:57 PM, "Martin v. Löwis" wrote:
> While I have your attention, please also review
>
> http://bugs.python.org/issue6233
I'm pretty sure that fix is the wrong fix - afaik, _encode is used to
encode tag/attribute names, and charrefs don't work in that context.
___
it's revews like this that makes me wonder if releasing open source is
a good idea:
no egg - worst seen ever, remove it from pypi or provide an egg
(jensens, 2009-10-05, 0 points)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
On Mon, Oct 5, 2009 at 10:43 AM, Fredrik Lundh wrote:
> it's reviews like this that makes me wonder if releasing open source is
> a good idea:
>
> no egg - worst seen ever, remov
d stuff *before* they did that. That *is* a community problem.
(Luckily, there are people helping out, and the "nice people
driven-development" rule overrides that other rule I mentioned, so
things will get tweaked sooner or later.)
On Mon, Oct 5, 2009 at 1:02 PM, Nick Coghlan wro
On Mon, Oct 5, 2009 at 8:48 PM, P.J. Eby wrote:
> names for the same thing. (I'm guessing that PIL was registered on PyPI
> manually, before the "setup.py register" command existed. Heck, it was
> probably being distributed before the distutils even existed, and indeed
> before there were such
Jeremy Hylton wrote:
> To express this email in the positive form:
> 1. Reserved words should be real words.
> 2. The meaning of the word should be clear.
> 3. "Put statements in positive form." (Strunk & White)
> 4. The word should sound good.
agreed. a word should describe what a thing is, no
Talin wrote:
> I also think that it won't be a complete disaster if we do nothing at
> all - there *are* existing ways to deal with this problem; there are
> even some which aren't hackish and non-obvious. For example, its easy
> enough to create an object which acts as an artificial scope:
>
Peter Åstrand wrote:
> I intend to fix bug #1223937: subprocess.py abuse of errno. I thought
> this was going to to tricky, to maintain backwards compatibility, but
> then I realized that check_call() and CalledProcessError() are not
> available in any released version of Python, so I guess it'
Boris Borcic wrote:
>>> I believe that in this case native linguistic intuition made the decision...
>>
>> The reason has nothing to do with language. Guido didn't
>> want sum() to become an attractive nuisance by *appearing*
>> to be an obvious way of joining a list of strings, while
>> actually
Boris Borcic wrote:
>> in what language [is] the word "sum" an appropriate synonym for
>> "concatenate" ?
>
> any that admits a+b to mean ''.join([a,b]), I'd say.
and what human language would that be ?
___
Python-Dev mailing list
Python-Dev@pyth
Georg Brandl wrote:
> Late it comes, but here is a patch for getopt.c implementing
> this pronouncement. I think there's no need to wait for 2.6 with it,
> or is there?
check it in already.
___
Python-Dev mailing list
Python-Dev@python.org
http://
Boris Borcic wrote:
>> note that most examples of this type already work, if the target type is
>> mutable, and implement the right operations:
>>
>> def counter(num):
>> num = mutable_int(num)
>> def inc():
>> num += 1
>> return num
>>
given that java has beaten us with some 60 bytes:
http://programming.reddit.com/info/9xha/comments/c9y8b
and in order to further improve Python's Kolmogorov rating:
http://en.wikipedia.org/wiki/Kolmogorov_complexity
how about adding Peter Norvig's constraint-based solver to the Python l
[EMAIL PROTECTED] wrote:
> He clearly wasn't fully master of the environment in which his
> customers ran his software, so I think it's understandable that he was
> caught by surprise by this change.
a programmer that's surprised that code that relies on undocumented behaviour
might behave differ
Bob Ippolito wrote:
>> What do you mean by "open classes"? Python
>> classes already seem pretty open to me, by
>> the standards of other languages!
>
> I'm guessing he's talking about being like Ruby or Objective-C where
> you can add methods to any other class in the runtime.
wouldn't a standar
"K.S.Sreeram" wrote:
> (just waiting for somebody to give a serious explanation on why this is
> a bad idea!)
\F might have to post this to comp.lang.python first...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Nick Coghlan wrote:
>> The person whose 'complaints' I was stating says that DSLs (Domain
>> Specific Languages for those who, like me, were confused about the
>> acronym) are a big part of what he is after and one per interpreter is
>> fine by him. He also realises that the application(s) he need
Thomas Heller wrote:
> Naturally I tried to call base64.encodestring(buffer(ctypes_instance))
> and it worked, so that was my answer.
does ctypes_instance implement the buffer API ? if it does, is the
buffer() call even necessary ?
___
Python-Dev m
Thomas Heller wrote:
>>> Naturally I tried to call base64.encodestring(buffer(ctypes_instance))
>>> and it worked, so that was my answer.
>>
>> does ctypes_instance implement the buffer API ? if it does, is the
>> buffer() call even necessary ?
>
> Yes, in both cases.
are you sure? does it i
Talin wrote:
>> I think python should have a couple more of future imports. "from __future__
>> import new_classes" and "from __future__ import unicode_literals" would be
>> really welcome, and would smooth the Py3k migration process
>
> Actually - can we make new-style classes the default, but a
Fred L. Drake, Jr. wrote:
> It feels like the release cycle from alpha1 to final has gotten increasingly
> rushed.
python 2.2: ~5 months
python 2.3: ~7 months
python 2.4: ~5 months
python 2.5: ~4 months
I think the biggest problem is the time between "basically stable beta"
and "final"; it was
Neal Norwitz wrote:
> Given that several people here think we should lengthen the schedule
> in some way, I suspect we will do something. I'm not really against
> it, but I don't think it will provide much benefit either. A few more
> bugs will be fixed since we have more time.
you're still mis
Neal Norwitz wrote:
> This is the part I don't get. For the external developers, if they
> care about compatibility, why aren't they testing periodically,
> regardless of alpha/beta releases?
because they don't want to waste time and effort on testing against
releases that are not necessarily a
Nick Maclaren wrote:
>> I don't think that applies to the Python args[] though,
>> since its args[0] isn't the path of the OS-level
>> executable, it's the path of the main Python script.
>
> Oh, yes, it does! The file descriptor or inode number could refer to
> the script just as well as it cou
"A.M. Kuchling" wrote:
>> While the new python.org is very nice, I do note that there's no "blogs"
>> entry on the front page, something which has become a fixture on almost
>> every other website I visit regularly.
>
> A 'Blogs' link could be trivially added by linking to
> planet.python.org, thou
"Chris S" wrote:
> and while most users and the w3 spec
> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting)
> agree this feature is actually a bug
ET's not a canonicalization library, and doesn't claim to be one, so that
reference isn't
very relevant. And "most users" know t
Martin v. Löwis wrote:
> That is not enough reason. Yes, it makes certain applications
> impossible, e.g. when namespace prefixes are inside attribute
> values. It just means you can't use it for that application,
> then. XML has many other applications, and so does ElementTree.
there are ways to
Ralf Schmitt wrote:
> any chance to get SimpleXMLWriter (and other modules maybe??) getting
> included into xml.etree? Otherwise people might have to stick to the
> original elementtree, which doesn't really make sense, since most of
> elementtree already is included.
the original decision was to
Guido van Rossum wrote:
> To be honest I have no idea how/why Martin or Tim picked this name.
> Perhaps it is in POSIX?
it's from sys/types.h, which is a posix thing, afaik:
http://www.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
___
P
John J Lee wrote:
> If nobody has time to fix this, perhaps rev 47154 should be reverted?
yes please.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
Georg Brandl wrote:
>> The example code causes segfaults and probably always has (at last to 2.2)
>
> Interesting! From a naive POV, the docs' example is quite right.
except that it doesn't work?
the problem is that it's using a *high-level* API to manipulate objects
that are not properly init
Georg Brandl wrote:
> Okay, now that I stumbled over and read the c.l.py thread, I think that we
> should
>
> * remove the faulty example (the correct one is already in there)
> * add a note to PyList_New that the new list must be filled with items
>before handing it to Python code or using
Martin v. Löwis wrote:
> It isn't. Python ran on 64-bit Alpha for nearly a decade now (I guess)
make that "over a decade". the first Python system I built was on
tru64, back in 1995 (portions of the the initial prototype was written
on a 286 box under MS-DOS, but the bulk was developed on tru6
Alex Martelli wrote:
> Sprints are indeed a fascinating idea and have proven they work, in
> an open-source context -- I do wonder if they could be made to work
> in other contexts, and I'm sure many others are wondering similarly.
"war room" development and other colocation approaches are no
Neal Norwitz wrote:
> I've profiled various combinations. Here are the various results
> normalized doing xrange(0, 1e6, 1):
>
> Run on all integer (32-bit) values for start, step, end:
> C xrange and iter: 1
> Py xrange w/C iter: 1
in real life, loops are a lot shorter than that.
if you take
Guido van Rossum wrote:
> (*) I found an example of code testing "if string.find(s, t) != 0",
> thinking it was a bug attempting to write "if t in s", but which Vinay
> identified as a 1.5.2 idiom for "if not s.startswith(t)"...
and as noted on the py3k list, not a very good one, given that the u
Guido van Rossum wrote:
> I prefer to focus on "clearer" and "less error-prone" rather than
> "faster" in most cases.
well, given that "startwith" is by far the most common typo I make
when writing Python programs these days, I'm not so sure about that
error-proneness thing, but never mind...
>
Paul Moore wrote:
> One little addition to the elementtree docs. In the overview section,
> adding a paragraph explaining best practice for importing the module
> might be useful.
good idea.
> PS This actually begs the question - are there platforms where
> xml.etree.cElementTree is not availabl
Steve Holden wrote:
> Standards, apparently, are for *other* people :-)
ET was written years before the "certain modules should use camelcase" stuff
was removed from PEP 8. as a refresher for those of you who have trouble
remembering how things were back in early 2004, here's GvR's original styl
Muguntharaj Subramanian wrote:
> Hi All,
> I tried building python 2.5c1 using VC8.
>
> Getting the following errors while building pythoncore_pgo:
>
>Creating library pythoncore_pgo/python25.lib and object
> pythoncore_pgo/python25.exp
> config.obj : error LNK2001: unresolved external symbo
Muguntharaj Subramanian wrote:
> That error mentioned in that post was in "pythoncore" module.
> My error is while compiling "pythoncore_pgo" module.
iirc, that's a partially experimental alternative build for playing with
performance guided optimizations. are you sure you need that module ?
"Johann C. Rocholl" wrote:
> What is the status of http://effbot.org/lib/ ?
>
> I think it's a step in the right direction. Is it still in progress?
the pushback from the powers-that-be was massive, so we're currently working
"under
the radar", using alternative deployment approaches (see pytut.
Greg Ewing wrote:
> Actually I'd like this for lists. Often I find myself
> writing
>
> if x not in somelist:
> somelist.remove(x)
>
> A single method for doing this would be handy, and
> more efficient.
there is a single method that does this, of course, but you have to sprinkle
some sugar
Raja Rokkam wrote:
> I would like to code in Python , but i am new to Python Network Programming
wrong list: python-dev is for people who develop the python core, not people
who want to develop *in* python.
see
http://www.python.org/community/lists/
for a list of more appropriate forums.
Anthony Baxter wrote:
>
The plan for 2.4.4 is to have a release candidate on October 11th, and
a final
> release on October 18th. This is very likely to be the last ever 2.4 release,
> after which 2.4.4 joins 2.3.5 and earlier in the old folks home
"finally leaves school" is a more correct de
[EMAIL PROTECTED] wrote:
> I think the right thing is for InteractiveConsole to dup sys.std{in,out,err}
> and do its own thing for its raw_input() method instead of naively calling
> the raw_input() builtin.
what guarantees that sys.stdin etc has a valid and dup:able fileno when
the console is i
Nick Craig-Wood wrote:
> Is there any reason why float() shouldn't cache the value of 0.0 since
> it is by far and away the most common value?
says who ?
(I just checked the program I'm working on, and my analysis tells me
that the most common floating point value in that program is 121.216,
w
Simon Brunning wrote:
> The "How to use this module" sections sound like /F's "The Python
> Standard Library", of which I keep the dead tree version on my desk
> and the PDF vesion on my hard drive for when I'm coding in the pub. It
> or something like it would be a superb addition to the (already
Jack Jansen wrote:
> I was wondering: how many other people who maintain websites (well:
> "maintain" might be a bit of a misnomer in my case:-) related to
> Python have also got this spam?
probably everyone. I've gotten two copies, this far.
__
Terry Reedy wrote:
> For true floating point measurements (of temperature, for instance),
> 'integral' measurements (which are an artifact of the scale used (degrees F
> versus C versus K)) should generally be no more common than other realized
> measurements.
a real-life sensor is of course w
just noticed that the first google hit for "what's new in python 2.5":
http://docs.python.org/dev/whatsnew/whatsnew25.html
points to a document that's a weird mix between that actual document, and
a placeholder for "what's new in python 2.6".
Steve Holden wrote:
> instance.method(*args) <==> type.method(instance, *args)
>
> You can nowadays spell this as str.join("", lst) - no need to import a
> whole module!
except that str.join isn't polymorphic:
>>> str.join(u",", ["1", "2", "3"])
Traceback (most recent call last):
File "",
[EMAIL PROTECTED] wrote:
> Greg> have you run any generic benchmarks such as pystone to get a
> Greg> better idea of what the net effect on "typical" python code is?
>
> MAL's pybench would probably be better for this presuming it does some
> addition with string operands.
or stringbench
Ron Adam wrote:
> I think what may be missing is a larger set of higher level string functions
> that will work with lists of strings directly. Then lists of strings can be
> thought of as a mutable string type by its use, and then working with
> substrings
> in lists and using ''.join() will
Nicko van Someren wrote:
> If it speeds up pystone by 5.5% with such minimal down side
> I'm hard pressed to see a reason not to use it.
can you tell me where exactly "pystone" does string concatenations?
___
Python-Dev mailing list
Python-Dev@pyth
Talin wrote:
> /*
>Plot a point at position x, y.
>'x' - The x-coordinate.
>'y' - The y-coordinate.
> */
> void Plot( int x, int y );
>
> The scanner should note that: 'x' and 'y' are in single-quotes, so they
> probably refer to code identifiers.
or maybe th
Chuzo Okuda wrote:
> I received the bounced email as follow. How do I become a member?
the moderator has approved your message, and it has reached the right
persons. I'm sure they'll get back to you soon.
___
Python-Dev mailing list
Python-Dev@pyth
Tim Lesher wrote:
> 1. Does this seem like a reasonable addition to the standard library?
I cannot remember ever doing this, or seeing anyone except Perforce
doing this, and it'll only save you a few lines of code every other year
or so, so my answer is definitely no.
(if you're serious about
> I forgot the import statement (especially the * version)
not only that, you also forgot what mailing list you were posting to...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
"Neal Becker" <[EMAIL PROTECTED]> wrote:
> http://www.google.com/codesearch?q=+doc:DxlBcBw4TXo+proprietary+confidential+show:DxlBcBw4TXo:BwgQSUaGDCc:1s0hP8rbIGE&sa=N&cd=1&ct=ri&cs_p=http://www.python.org/download/releases/binaries-1.3/python-IRIX-5.3-full.tar.gz&cs_f=lib/python/irix5/AWARE.py#a0
Josiah Carlson wrote:
> Presumably with this library you have created, you have also written a
> fast object encoder/decoder (like marshal or pickle). If it isn't any
> faster than cPickle or marshal, then users may bypass the module and opt
> for fork/etc. + XML-RPC
XML-RPC isn't close to marsh
Martin v. Löwis wrote:
> Of course, if everybody would always recompile all extension modules
> for a new Python feature release, those flags weren't necessary.
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension
I wrote:
>PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods);
methods and members could of course be registered to, so the implementation can
chose
how to store them (e.g. short lists for smaller method lists, dictionaries for
others).
___
Josiah Carlson wrote:
> It would basically be something along the lines of cPickle, but would
> only support the basic types of: int, long, float, str, unicode, tuple,
> list, dictionary.
if you're aware of a way to do that faster than the current marshal
implementation, maybe you could work on
Greg Ewing wrote:
>> if you're aware of a way to do that faster than the current marshal
>> implementation, maybe you could work on speeding up marshal instead?
>
> Even if it weren't faster than marshal, it could still
> be useful to have something nearly as fast that used
> a python-version-in
Anthony Baxter wrote:
> 16 releases in 12 months would just about make me go crazy.
is there any way we could further automate or otherwise streamline or
distribute the release process ?
ideally, releasing (earlier release + well-defined patch set) should be
fairly trivial, compared to releasing
Armin Rigo wrote:
>> NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy));
>
> It doesn't address the problem Martin explained (you can put neither
> NULLs nor stubs in tp_xxx fields that are beyond the C extension
> module's sizeof(Nobby)). But I imagine it could with a bit more
> tweaking
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
>> marshal hasn't changed in many years:
>
> Maybe not, but I was given to understand that it's
> regarded as a private format that's not guaranteed
> to remain constant across versions. So even if
> it hap
Brett Cannon wrote:
> I know AMK was experimenting with rest2web as a possible way to do the
> web site. There has also been talk about trying out another system.
> But I also know some people would rather put the effort into improving
> Pyramid.
You forgot the ponies!
> Once again, it's a
Anthony Baxter wrote:
> The other thing to watch out for is that I (or whoever) can still do local
> work on a bunch of different files
the point of my previous post is that you *shouldn't* have to edit a
bunch of different files to make a new release.
___
Alexey Borzenkov wrote:
> P.S. Although it's a bit stretching, one might also say that
> implementing spawn*p* on windows is not actually a new feature, and
> rather is a bugfix for misfeature. Why every other platform can
> benefit from spawn*p* and only Windows can't? This just makes
> os.spawn*
Anthony Baxter wrote:
>> For reference, here's my effbot.org release procedure:
>>
>> 1) upload the distribution files one by one, as soon as they're
>> available. all links and stuff will appear automatically
>>
>> 2) update the associated description text through the web, when
>> necessary, as
Nick Coghlan wrote:
> > would collapse to
> >
> > static PyTypeObject NoddyType;
>
> Wouldn't that have to be a pointer to allow the Python runtime complete
> control of the structure size without recompiling the extension?:
>
> static PyTypeObject *NoddyType;
yeah, that's a silly typo.
Anthony:
>> Sure - I get that. There's a couple of reasons for me doing it. First is gpg
>> signing the release files, which has to happen on my local machine. There's
>> also the variation in who actually builds the releases; at least one of the
>> Mac builds was done by Bob I. But there could be
Alexey Borzenkov wrote:
>> any reason you cannot just use the "subprocess" module instead, like
>> everyone else?
>
> Oh! Wow! I just simply didn't know of its existance (I'm pretty much
> new to python), and both distutils and SCons (I was looking inside
> them because they are major build system
Martin v. Löwis wrote:
> In 2.3.6, there wouldn't just be that change, but also a few other
> changes that have been collected, some relevant for Windows as well
why not just do a "2.3.5+security" source release, and leave the rest to the
downstream maintainers?
Steve Holden wrote:
> Or you can start to promote Django again ...
my original plan would still work, I think:
http://effbot.org/zone/pydotorg-cache.htm#todo
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
Anthony Baxter wrote:
> > why not just do a "2.3.5+security" source release, and leave the rest to
> > the downstream maintainers?
>
> I think we'd need to renumber it to 2.3.6 at least, otherwise there's the
> problem of distinguishing between the two. I'd _hope_ that all the
> downstreams will h
Larry Hastings wrote:
> I knocked out a prototype of this last week, emailed Mr. Lundh about it,
> then forgot about it.
It's on my TODO list, so I haven't forgotten about it, but I've been (as
usual) busy with other stuff. I'll get there, sooner or later.
Posting this to the patch tracker an
Talin wrote:
> Interesting - is it possible that the same technique could be used to
> hide differences in character width? Specifically, if I concatenate an
> ascii string with a UTF-32 string, can the up-conversion to UTF-32 also
> be done lazily?
of course.
and if all you do with the resul
Josiah Carlson wrote:
> It would be a radical change for Python 2.6, and really the 2.x series,
> likely requiring nontrivial changes to extension modules that deal with
> strings, and the assumptions about strings that have held for over a
> decade.
the assumptions hidden in everyone's use of th
Larry Hastings wrote:
> Am I correct in understanding that changing the Python minor revision
> number (2.5 -> 2.6) requires external modules to recompile?
not, in general, on Unix. it's recommended, but things usually work
quite well anyway.
___
[EMAIL PROTECTED] wrote:
> I'm not sure what a "pebkac" problem is.
http://en.wikipedia.org/wiki/PEBKAC
You'll learn some new nonsense every day ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Talin wrote:
>> You probably want to use the posixpath module directly in that case,
>> though perhaps you've already discovered that.
>
> Never heard of it. Its not in the standard library, is it? I don't see
> it in the table of contents or the index.
http://effbot.org/librarybook/posixpath.
Josiah Carlson wrote:
> I think that even on 64 bit platforms, using 'int' or 'long' generally
> means 32 bit. In order to get 64 bit ints, one needs to use 'long long'.
real 64-bit platforms use the LP64 standard, where long and pointers are
both 64 bits:
http://www.unix.org/version2/wha
Talin wrote:
> I'm right in the middle of typing up a largish post to go on the
> Python-3000 mailing list about this issue. Maybe we should move it over
> there, since its likely that any path reform will have to be targeted at
> Py3K...?
I'd say that any proposal that cannot be fit into the
Terry Reedy wrote:
> I believe that at present PyGame can only work with external images that it
> is programmed to know how to import. My guess is that if image source
> program X (such as PIL) described its data layout in a way that NumPy could
> read and act on, the import/copy step could b
[EMAIL PROTECTED] wrote:
> I am not addressing this message to the py3k list because its general
> message of extreme conservatism on new features is more applicable to
> python-dev. However, py3k designers might also take note: if py3k is
> going to do something in this area and drop support
Jonathan Lange wrote:
> Then let us discuss that.
Glyph's references to bike sheds went right over your head, right?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
[EMAIL PROTECTED] wrote:
> I assert that it needs a better[1] interface because the current
> interface can lead to a variety of bugs through idiomatic, apparently
> correct usage. All the more because many of those bugs are related to
> critical errors such as security and data integrity.
in
Chris Barker wrote:
> While /F suggested we get off the PIL bandwagon
I suggest we drop the obsession with pointers to memory areas that are
supposed to have a specific format; modern data access API:s don't work
that way for good reasons, so I don't see why Python should grow a
standard based
Steve Holden wrote:
> Although the last two smell like bugs, the point of urljoin is to make
> an absolute URL from an absolute ("current page") URL
also known as a base URL:
http://www.w3.org/TR/html4/struct/links.html#h-12.4.1
(os.path.join's behaviour is also well-defined, btw; if any
Martin v. Löwis wrote:
> However, I find the proposed behaviour reasonable: Python already
> automatically imports the .pyc file if .py is not given and vice
> versa. So why not look for .pyo if the .pyc file is not present?
well, from a performance perspective, it would be nice if Python looked
Steve Holden wrote:
>> Ah, but how do you know when that's wrong? At least under ftp:// your
>> root is often a mid-level directory until you change up out of it.
>> http:// will tend to treat the targets as roots, but I don't know that
>> there's any requirement for a /.. to be meaningless (even
Martin v. Löwis wrote:
> Andrew Dalke schrieb:
> urlparse.urljoin("http://blah.com/";, "..")
>> 'http://blah.com/'
> urlparse.urljoin("http://blah.com/";, "../")
>> 'http://blah.com/../'
> urlparse.urljoin("http://blah.com/";, "../..")
>> 'http://blah.com/'
>>
>> Does the result make s
Andrew Dalke wrote:
>> as I said, today's urljoin doesn't guarantee that the output is
>> the *shortest* possible way to represent the resulting URI.
>
> I didn't think anyone was making that claim. The module claims
> RFC 1808 compliance. From the docstring:
>
> DESCRIPTION
> See
Guido van Rossum wrote:
> No objection on targetting 2.6 if other developers agree. Seems this
> is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir() behaviour. *adding* to the defaul
Thomas Heller wrote:
>>> No objection on targetting 2.6 if other developers agree. Seems this
>>> is well under way. good work!
>>
>> given that dir() is used extensively by introspection tools, I'm
>> not sure I'm positive to a __dir__ that *overrides* the standard
>> dir() behaviour. *adding*
1 - 100 of 732 matches
Mail list logo
