Trent Mick wrote:
That is the current state.
which reminds that maybe it's time to add an import helper to
the standard library, so you can do
stringio = import_search(cStringIO, StringIO)
ET = import_search(lxml.etree, cElementTree, xml.etree.cElementTree)
db =
Bob Ippolito wrote:
Try the 2.5 alpha 1 just released, and you'll see that the toplevel
package is now xml.etree. The module and class are still called
ElementTree, though.
It would be nice to have new code be PEP 8 compliant..
it's not new code, and having *different* module names for
Thomas Wouters wrote:
The webpage should be made, though, if just to refer to in the
release notes.
the web page does exist:
http://www.python.org/dev/peps/pep-0353/#conversion-guidelines
/F
___
Python-Dev mailing list
Python-Dev@python.org
the source code is available via the above link; I'll post the ZIP file some-
where tomorrow (drop me a line if you want the URL).
I found some free space on the effbot.org server, so anyone inter-
ested can get the current ZIP file here:
http://effbot.org/tracker-20060403.zip
the zip
Martin v. Löwis wrote:
That isn't actually worth that much: somebody would need to operate it,
too. Mere existence doesn't help.
why do you keep repeating this when I've already posted a link to a
company that does this for only a few bucks per month ?
/F
Brett Cannon wrote:
oh, I forgot that the Procrastination Stop energy Foundation was involved
in this.
Fredrik, if you would like to help move this all forward, great; I
would appreciate the help. You can write a page scraper to get the
data out of SF if you don't believe SF will
Brett Cannon wrote:
oh, I forgot that the Procrastination Stop energy Foundation was involved
in this.
Fredrik, if you would like to help move this all forward, great; I
would appreciate the help. You can write a page scraper to get the
data out of SF
challenge accepted ;-)
Georg Brandl wrote:
it's time for the 7th Python Bug Day. The aim of the bug day is to close
as many bugs, patches and feature requests as possible, this time with a
special focus on new features that can still go into the upcoming 2.5 alpha
release.
so, how did it go? a status report /
Fredrik, if you would like to help move this all forward, great; I
would appreciate the help. You can write a page scraper to get the
data out of SF
challenge accepted ;-)
http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/
contains three basic tools; getindex to grab
Greg Ewing wrote:
Firebird could be a solution to this.
so a library that doesn't support multiple independent
readers/writers on a single file at all is much better
than one that does,
Where do you get that from? Firebird supports
multiple readers/writers perfectly well.
not
Anthony Baxter wrote:
xml.dom.minidom?
given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to
use the xml package as an example of _anything_ wink
which reminds me -- is that issue still open ? martin? fred?
/F
___
Python-Dev
Anthony Baxter wrote:
It looks to me like it's fixed in SVN.
http://mail.python.org/pipermail/python-dev/2005-December/058710.html
the issue isn't the one in that message though; it's the one in this message:
http://mail.python.org/pipermail/python-dev/2005-December/058752.html
I
Georg Brandl wrote:
What I answered to was:
from what I can tell, no big contemporary Python project use Atlassian.
they all use Trac. there are thousands of Python developers out there
that are used to working with Trac.
I'm obviously missing something here.
I'm not saying it's out
Anthony Baxter wrote:
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that sqlite was the name used by the first pysqlite
generation:
$ python2.3
import sqlite
sqlite.version
'1.1.6'
I'm not sure how much
Martin v. Löwis wrote:
I'm obviously missing something here.
One thing that you are *obviously* missing (there might be more):
Nobody has stepped forward and said I make trac happen. Without
somebody (specific) saying that, all technical arguments in favour
of that software are futile.
Brett Cannon wrote:
Same here. Please move any more comments about infrastructure to the
infrastructure list
(http://mail.python.org/mailman/listinfo/infrastructure/). But
do realize the committee is not discussing trackers yet. We are still
trying to get our SF data out so that can be
Tim Peters wrote:
[Georg Brandl]
for the Bug Day, someone asked me if there is a prebuilt trunk
for Windows available somewhere so that he could participate.
Martin: I read you've built for a snapshot AMD64, is there one for x86 too?
If someone can explain what prebuilt trunk means,
Guido van Rossum wrote:
I can ask them for a test py3k account, if there's any interest.
I'm personally not very much interested in a Py3k tracker; I don't
see myself using it. So I'm not interested in a trac-based one,
either.
Me neither. It's too early.
I wasn't really expecting
Robert Kern wrote:
Apologies: for the other blank reply.
oh, I don't know about that -- the eco quote made perfect sense ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Anthony Baxter wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules
was planned.
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package
Georg Brandl wrote:
Generally, I like Trac very much, especially for its interconnected
subsystems.
I've used it with smaller projects, and there it works perfectly.
Having said that, I don't know if the Trac ticket system (which would be the
most important subsystem for us) scales up well
Robert Brewer wrote:
More Against?:
Explaining database is locked errors (due to SQLite's exposed
multiple-readers/one-writer design) on a daily basis (FAQ entries
notwithstanding).
wow. that's one quality argument. what's wrong with you ?
/F
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've
never seen sqlite, and I've ignored this thread, so I don't know what
the disagreement is all about.
what disagreement ?
sqlite is a widely used light-weight SQL library (http://www.sqlite.org)
that's
gerald's pysqlite binding
sorry, gerhard.
/F
___
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
[EMAIL PROTECTED] wrote:
I haven't been tracking the pysqlite discussion either, but one con you
missed is that regardless of pro #1 people will almost certainly apply it to
problems for which it is ill-suited, reflectly poorly on both Python and
SQLite.
the arguments keep getting more and
Brett Cannon wrote:
Wouldn't the newly founded python-3000 mailing list be the perfect place
for such major changes?
If you go back and look at Guido's Python 3000 Process email he said
that the change could occur in 2.6 and then be done for 3000.
Renaming modules is not that hard to make
Bill Janssen wrote:
On the package naming issue: using em for email would be wrong,
just as db for database would be wrong.
are you aware of the fact that the module implements the db-api ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Greg Ewing wrote:
Firebird could be a solution to this. It can be
used in a mode that doesn't need a server, and it
has no trouble at all with concurrency or large
amounts of data that I know of.
so a library that doesn't support multiple independent readers/writers on
a single file at all
Neal Norwitz wrote:
I'm in favor of having Atlassian setup a system to be used for 3k. It
would be completely experimental and could be completely thrown away
which should be made clear to Atlassian if we were to do this. I
would use the system for evaluation.
so what's the advantage of a
Gerhard Häring wrote:
I know that pushing new things into Python 2.5 should happen soon, if at
all. So *if* pysqlite should go into Python, I propose that I release
pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
If this is going to happen, I want it to happen under
neal.norwitz wrote:
+Outstanding Issues
+==
+
+* Require C99, so we can use // comments, named initializers, declare
variables
+ without introducing a new scope, among other benefits.
gcc only, in other words ?
+* Remove support for old systems, including: OS2, BeOS,
Michael Hudson wrote:
+* Remove support for old systems, including: OS2, BeOS, RISCOS, (SGI)
Irix, Tru64
what's old with tru64 ? it's not that uncommon in places where Python
has a strong presence, you can still buy AXP hardware throughout 2006,
and HP says they'll keep developing
Michael Hudson wrote:
The ssize_t patch is the single most disruptive patch in
Python 2.5, so it deserves special attention.
From your POV, maybe: from mine, it's definitely the new compiler.
in what way does the new compiler affect third-party developers ?
/F
M.-A. Lemburg wrote:
Here's a grep of all the changed/new APIs, please include it
in the PEP.
I've posted a simple-minded source scanner here:
http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py
/F
___
Python-Dev mailing list
M.-A. Lemburg wrote:
Perhaps we should have three lists:
1. Py_ssize_t output parameters (these need changes)
2. Py_ssize_t return values (these need overflow checks)
3. Py_ssize_t input parameters (these can be used to enhance
the extension)
Here's the list for 2 (I already provided
Martin v. Löwis wrote:
There are two improvements you could make:
- Some of the functions in the first list return Py_ssize_t; calling
them can cause truncation if the result value is larger than INT_MAX
(and it is assigned to an int). To find those functions, do
grep
Neal Norwitz wrote:
Just in case anybody here's been snoozing, 2.5 alpha 1 is coming up
real quick, hopefully within a couple of weeks. If you have any
*major* features (particularly implemented in C) that you want to see
in 2.5, bring it up now. I want to strive for feature completeness by
Fred L. Drake, Jr. wrote:
Fredrik Lundh wrote:
d) If Python was started from a standard Python interpreter,
My understanding matches Guido's description, so I'm not sure any changes are
needed.
the problem with that is that your understanding doesn't match the
implementation
(which
Guido van Rossum wrote:
For finding related files, sys.exec_prefix and sys.prefix should be used
except that they're defined in terms of where the standard library is:
prefix -- prefix used to find the Python library
exec_prefix -- prefix used to find the machine-specific Python
a) sys.executable points to the executable that was used to load the
Python interpreter library/dll.
this use is supported by the docstring and the implementation, and is
quite
common in the wild. an application using this interpretation may
Thomas:
py2exe
Martin v. Löwis wrote:
On the other hand, the exploit could be crafted based on reading the SVN
check-ins ...
Sure. However, at that point, the bug is fixed (atleast in SVN);
crackers need to act comparatively fast then to exploit it. OTOH, if
only the report was available, the project
(there's still a possibility that someone checks in a fix without realizing
that
the original bug is an attack vector, but I don't think Coverity has
discovered
anything like that in the Python code base; we're mainly talking about leaks
and null-pointer references here).
to clarify,
return=NULL; output=junk = out of memory
return=junk; output=-1 = cannot do this
return=pointer; output=value = did this, returned value bytes
I agree that the design is a bit questionable;
It sure is. If you get both NULL and -1 returned, how are
you supposed to know which
Martin v. Löwis wrote:
Jean-Paul Calderone wrote:
It should actually be using TerminateProcess (depending on the
Twisted version being used, the relevant code is either in
twisted/internet/_dumbwin32proc.py or
twisted/internet/win32eventreactor.py, in the signalProcess method in
either
Greg Ewing wrote:
Fredrik Lundh wrote:
return=NULL; output=junk = out of memory
return=junk; output=-1 = cannot do this
return=pointer; output=value = did this, returned value bytes
I agree that the design is a bit questionable;
It sure is. If you get both NULL and -1
fermigier [EMAIL PROTECTED] wrote:
Perl had a defect density of only 0.186. In comparison Python had a
defect density of 0.372 and PHP was actually above both the baseline and
LAMP averages at 0.474.
This is of course a PR stunt. But I'm wondering if the actual bugs
list was transmitted to
fermigier wrote:
But I'm wondering if the actual bugs list was transmitted to Python
developers,
and verified / acted upon.
and in case it wasn't clear from my previous post, the answer to
your specific question is yes ;-)
/F
___
Python-Dev
see subject and http://python.org/sf/1368955
comments ?
/F
(note sure how my previous attempt to post this ended up on
comp.lang.python instead, but I'll blame it on gmane... ;-)
___
Python-Dev mailing list
Python-Dev@python.org
Alex Martelli wrote:
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
...
I think that adding parentheses would help, by at least signalling
that the logic is longer than just the next (single) expression.
level = (0 if absolute_import in self.futures else -1)
+1 (just because I
Raymond Hettinger wrote:
This conversation is getting goofy.
indeed.
let's pray that nobody that is considering picking up Python sees this
thread.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
I don't think a change like this should go into a 2.4.x release. It
stands a very very high chance of breaking someone's code. I _could_
be convinced about a warning being emitted about it, though I'm not
going to have the time to figure out the new compiler to do
Raymond Hettinger wrote:
When teaching your classes, do you sense an aversion to using double
underscore methods in regular code? I sense an implied message that
these methods are not intended to be called directly (i.e. the discomfort
of typing x.__setitem__(k,v) serves as a cue to write
Tim Peters wrote:
For simpler fun, run this silly little program, and look at memory
consumption at the prompts:
x = []
for i in xrange(100):
x.append([])
raw_input(full )
del x[:]
raw_input(empty )
For example, in a release build on WinXP, VM size is about 48MB at the
full
[EMAIL PROTECTED] wrote:
The docstring shows how to use it. Yet another Andrew Kuchling gem
as I recall (or maybe an effbot gem).
amk, most likely.
and in 92.65% of all cases, switching from regex to re involves adding
\ in front of (, | and ) if they don't already have them, and removing \
Thomas Wouters wrote:
I added webstats for all subsites of python.org:
http://www.python.org/webstats/
what's that Java/1.4.2_03 user agent doing? (it's responsible for
10% of all hits in january/february, and 20% of the hits today...)
/F
___
Facundo Batista wrote:
After a small talk with Raymond, yesterday in the breakfast, I
proposed in PyAr the idea of start to translate the Library Reference.
You'll agree with me that this is a BIG effort. But not only big, it's
dynamic!
So, we decided that we need a system that provide us
[EMAIL PROTECTED] wrote:
it's about time that someone sat down and merged the string and unicode
implementations into a single stringlib code base (see the SRE sources for
an efficient way to do this in plain C). [1]
[...]
1) anyone want me to start working on this ?
This would be a
Greg Ewing wrote:
Fredrik Lundh wrote:
moving to (basic) C++ might also be a good idea (in 3.0, perhaps). is any-
one still stuck with pure C89 these days ?
Some of us actually *prefer* working with plain C
when we have a choice, and don't consider ourselves
stuck with it.
perhaps
Raymond Hettinger wrote:
Like autodict could mean anything.
fwiw, the first google hit for autodict appears to be part of someone's
link farm
At this website we have assistance with autodict. In addition to
information for autodict we also have the best web sites concerning
Raymond Hettinger wrote:
Aside: Why on_missing() is an oddball among dict methods. When
teaching dicts to beginner, all the methods are easily explainable ex-
cept this one. You don't call this method directly, you only use it
when subclassing, you have to override it to do anything
Georg Brandl wrote:
I've just checked in some enhancements to the fileinput module.
* fileno() to check the current file descriptor
* mode argument to allow opening in universal newline mode
* openhook argument to allow transparent opening of compressed
or encoded files.
Please feel
Bob Ippolito wrote:
Doesn't this discussion belong on c.l.p / python-list?
yes, please.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Aahz wrote:
In all fairness to Tim (and despite the fact that emotionally I agree
with you), the fact is that there had been essentially no forward motion
on www.python.org redesign until he went to work. Even if we end up
chucking out all his work in favor of something else, I'll consider
Guido van Rossum wrote:
A bunch of Googlers were discussing the best way of doing the
following (a common idiom when maintaining a dict of lists of values
relating to a key, sometimes called a multimap):
if key not in d: d[key] = []
d[key].append(value)
/.../
Feedback?
+1. check it
Michael Hudson wrote:
OTOH, even if we didn't rename str/unicode to text, opentext would
still be a good name for the function that opens a text file.
Hnnrgh, not really. You're not opening a 'text', nor are you
constructing something that might reasonably be called an 'opentext'.
Martin v. Löwis wrote:
Also, I think has_key/in should return True if there is a default.
and keys should return all possible key values!
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Georg Brandl wrote:
as Jim Jewett noted, multifile is supplanted by email as much as mimify etc.
but it is not marked as deprecated. Should it be deprecated in 2.5?
-0.5 (gratuitous breakage).
I think the current see also/supersedes link is good enough.
/F
Nick Coghlan wrote:
Using Guido's original example:
d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Bengt Richter wrote:
because there's no way to count to 10 if you only have one digit?
we used to think that back when the gas price was just below 10 SEK/L,
but they found a way...
IIRC Guido is on record as saying There will be no Python 2.10 because
I hate the ambiguity of
Terry Reedy wrote:
I'd say we let the BDFL roam free.
PEPs are useful for question-answering purposes even after approval. The
design phase can be cut short by simply posting the approved design doc.
not for trivialities. it'll take Guido more time to write a PEP than to
implement the
(my mails to python-dev are bouncing; guess that's what you get when
you question the PSF's ability to build web sites... trying again.)
Neal Norwitz wrote:
(is the xmlplus/xmlcore issue still an issue, btw?)
What issue are you talking about?
the changes described here
Talin wrote:
So the general notion is similar to the various proposals on the Wiki -
an inline keyword which serves the function of lambda. I chose the
keyword given because it reminds me of math textbooks, e.g. given x,
solve for y. And I like the idea of syntactical structures that make
Paul Moore wrote:
I think most about everything has already been said wrt lambda already,
but I guess we could have a little war on spelling issues ;-)
Agreed, but credit to Talin for actually implementing his suggestion.
And it's nice to see that the AST makes this sort of experimentation
(is the xmlplus/xmlcore issue still an issue, btw?)
What issue are you talking about?
the changes described here
http://mail.python.org/pipermail/python-dev/2005-December/058710.html
I'd like to propose that a new package be created in the standard library:
xmlcore.
which led
Barry Warsaw wrote:
We know at least there will never be a 2.10, so I think we still have
time.
because there's no way to count to 10 if you only have one digit?
we used to think that back when the gas price was just below 10 SEK/L,
but they found a way...
/F
Adam Olsen wrote:
While we're at it, any chance of renaming str/unicode to text in 3.0?
It's a MUCH better name, as evidenced by the opentext/openbytes names.
str is just some odd C-ism.
Obviously it's a form of gratuitous breakage, but I think the long
term benefits are enough that we
Georg Brandl wrote:
If something like Fredrik's new doc system is adopted, it would be extremely
convenient to refer someone to just
docs.python.org/os.path.join
without looking up how the page is actually named.
you could of course reserve a toplevel directory for that purpose; e.g.
Martin v. Löwis wrote:
- is (c)ElementTree still planned for inclusion ?
It is included already.
in the xml.etree package, in case someone's looking for it in the
usual place.
that is,
import xml.etree.ElementTree as ET
import xml.etree.cElementTree as ET
will work in any 2.5
Georg Brandl wrote:
If something like Fredrik's new doc system is adopted
don't hold your breath, by the way. it's clear that the current PSF-sponsored
site overhaul won't lead to anything remotely close to a best-of-breed python-
powered site, and I'm beginning to think that I should spend my
Guido van Rossum wrote:
- it's probably too big to attempt to rush this into 2.5
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the
Thomas Wouters wrote:
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the design can get some real-world exposure in
Guido wrote:
I'm actually assuming to put this off until 2.6 anyway.
makes sense.
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
/F
___
Python-Dev mailing list
Python-Dev@python.org
Guido van Rossum wrote:
(Now that I work for Google I realize more than ever before the
importance of keeping URLs stable; PageRank(tm) numbers don't get
transferred as quickly as contents. I have this worry too in the
context of the python.org redesign; 301 permanent redirect is *not*
going
Fred L. Drake, Jr. wrote:
docs.python.org was created specifically to make searching the most recent
stable version of the docs easier (using Google's site: modifier, no less).
I don't know what the link count statistics say (other than what you
mention), and don't know which gets hit more
Donovan Baarda wrote:
Here I think you meant that medusa didn't handle computation in separate
threads instead.
No, I pretty much meant what I said :-)
Medusa didn't have any concept of a deferred, hence the idea of using
one to collect the results of a long computation in another thread
M, Raveendra Babu (STSD) wrote:
3)then /usr/ccs/bin/make
it is giving some errors and the error is :
gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-I. -I./Include -DPy_BUILD_CORE -o Python/pythonrun.o
Python/pythonrun.c
In file included from
Steve Holden wrote:
What is the reason that people want to use threads when they can have
poll/select-style message processing? Why does Zope require threads?
IOW, why would anybody *want* a threadsafe patch for asynchat?
In case the processing of events needed to block? If I'm
Terry Reedy wrote:
If 3.0 comes with a conversion program, then I would like to see 'lambda'
replaced with either 'def' or another abbreviation like 'edef' (expression
def) or 'func'.
making the implied return statment visible might also be a good idea, e.g.
lambda x, y: return x + y
or
Donovan Baarda wrote:
For Python 3000 you could extend this approach to lists and dicts;
[1,2,3] is a list, f[1,2,3] is a frozen list or tuple, {1:'a',2:'b'}
is a dict, f{1:'a',2:'b'} is a frozen dict which can be used as a key
in other dicts... etc.
Traceback (most recent call last):
File
Guido van Rossum wrote:
Ah. This definitely isn't what ConfigParser was meant to do. I'd think
for this you should use some kind of XML pickle though. That's
horrible if end users must edit it, but great for saving
near-arbitrary persistent data in a readable and occasionally editable
(for
Stephen J. Turnbull wrote:
Jason Filesystem paths are in fact strings on all operating
Jason systems I'm aware of.
I have no idea what you could mean by that. The data structure used
to represent a filesystem on all OS filesystems I've used is a graph
of directories and files. A
Gustavo J. A. M. Carneiro wrote:
If a URI class implemented the same methods, it would be something of a
question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz'
(and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does).
I assume it would be be the latter, and
BJörn Lindqvist wrote:
However, I might be wrong because according to [1] it should work. And
having to wrap the Path object in str() (open(str(somepath))) each and
every time the called function expects a string is not a practical
solution.
in Python, the usual way to access an attribute of
any progress ? does the script work in the buildbot setting, or
does it need tweaking ?
/F
Neal Norwitz wrote:
Does that make sense? We would just need /f's script in SVN.
in python/Tools/something or sandbox/something ?
python/Doc/tools/something?
Fredrik
Neal Norwitz wrote:
Does that make sense? We would just need /f's script in SVN.
in python/Tools/something or sandbox/something ?
python/Doc/tools/something?
Fredrik were you still working on that? I can make the changes to the
bb master. I thought Trent's suggested placement
Brett Cannon wrote:
And to /F, kudos from me. I have been randomly thinking about it and
I understand your desire for semantic markup now.
thanks.
Hopefully something can get hammered out so that at least the Python
3 docs can premiere having been developed on by the whole community.
why
I wrote:
Neal Norwitz wrote:
Does that make sense? We would just need /f's script in SVN.
in python/Tools/something or sandbox/something ?
python/Doc/tools/something?
Fredrik were you still working on that? I can make the changes to the
bb master. I thought Trent's
Gustavo J. A. M. Carneiro wrote:
# Operations on path strings.
def abspath(sef): ...
def normcase(self): ...
def normpath(self): ...
def realpath(self): ...
def expanduser(self): ...
def expandvars(self): ...
def
BJörn Lindqvist wrote:
Have you studied wikipedia's approach? It's multi-layered and worth
learning from (start with their FAQ on editing).
(And by the way, I am *not* advocating writing the docs as one big
wikipedia -- only the user commentary.)
to clarify, I'm advocating
Guido wrote:
What Fredrik hacks together there (http://www.effbot.org/lib) is very
impressive. I especially like the permalinks in this style:
http://effbot.org/lib/os.path.join
Which (despite having perma in its name) evaporates and leaves
behind a link to os.path.html#join.
301 - 400 of 622 matches
Mail list logo
