n
which the entries are kept sorted. (And I'm not sure that those are the
only two possibilities.)
I would be more in favor of the idea if we could come up with a less
ambiguous naming scheme.
-- Talin
___
Python-Dev mailing list
P
multiprocessing
Greg Ewing wrote:
Jesse Noller wrote:
I am looking for any questions, concerns or benchmarks python-dev has
regarding the possible inclusion of the pyprocessing module to the
standard library
Sounds good, but I'd suggest giving a more specific
name than "processing", which is
user, or implicitly as the result of a dependency, and (b) the
set of dependencies for this package.
Then, starting with the list of 'explicit' packages as the root set, do
a standard mark & sweep; Any package not marked is a candidate for removal.
-- Talin
___
efcount field of the object,
there's no need for locking.
-- Talin
___
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
g to enforce the rule consistently (and it seems as
if we're not), can we then just remove it from PEP 9? I'm not saying
that we should change the rule to one space, I'm suggesting that we just
drop the requirement and let people use whatever they prefer.
-- Talin
of the PEP, and in others I just write down what I think the
general consensus is.)
That being said - from what I've read so far, the evidence on both sides
of the argument seems anecdotal to me. I'd rather wait and see what more
people have to say on the topic.
-- Talin
Aurélien Cam
http://svn.python.org/view/peps/trunk/pep-3101.txt
Please let me know of any errors you find, either by mailing me
directly, or replying to the topic in Python-3000. (I.e. lets not start
a thread here.)
-- Talin
___
Python-Dev mailing list
Python-Dev@pytho
Greg Ewing wrote:
> Talin wrote:
>> As in the above example, the use of backticks can be signal to the
>> document processor that the enclosed text should be examined for
>> identifiers and other Python syntax.
>
> Does this mean it's time for "pyST"
c reasoning to determine the final markup. As in the
above example, the use of backticks can be signal to the document
processor that the enclosed text should be examined for identifiers and
other Python syntax.
I would also suggest that one test for evaluating the quality of m
. HTML versions of these documents are available
> at:
>
> * http://peak.telecommunity.com/DevCenter/PkgResources and
>
> * http://peak.telecommunity.com/DevCenter/EggFormats
>
> (These HTML versions are for setuptools 0.6; they may not reflect all
> of the changes found in
e spam a week on average, then this is all a moot point, its
less effort for someone to just manually delete it than it is to come up
with an automated system.
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
se I was afraid that the answer
would be that it's too hard / too late to do anything about it. I am
glad to have been proven wrong.
-- Talin
___
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
mer is trying to get
access to. When the human enters in the correct word, the spammer's
server sends that word to the target site, which result in a successful
login/registration. Now that the spammer is in, they can post comments
or whatever they need to do.
-- Talin
__
a
bug, which can automatically add them to a whitelist for future bug
submissions.
-- Talin
___
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
lifying
much - that is, the removals don't cascade and cause other
simplifications. The grammar file, for example, won't look dramatically
different if these changes are made. The simplification argument seems
weak to me because the change
Calvin Spealman wrote:
> Comments welcome, of course. Bare with my first attempt at crafting a PEP.
See below for comments; In general, I'm having problems understanding
some of the terms used. I don't have any comments on the technical
merits of the PEP yet, since I don't completely understand
Other than that, the summaries remain very valuable. Thank you :)
-- Talin
___
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
___
>> Need Mail bonding?
>> Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
>> http://answers.yahoo.com/dir/?link=list&sid=396546091
>>
>>
>>
>
> ___
> 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/talin%40acm.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
re about "DocLobster", which is my unpublished
prototype of a "subtle" markup language that tries to embed semantic
tags in the text, without causing the text to look like it has been
marked up.
-- Talin
___
Python-Dev mailing l
is
to gradually shrink the actual Stackless patches to the point where they
become small enough that a direct patch becomes uncontroversial.
-- Talin
___
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
quot;goals of this PEP" section:
>
>* To establish reStructuredText as a standard structured plaintext
> format for docstrings (inline documentation of Python modules and
> packages), PEPs, README-type files and other standalone documents.
>
>
> Talin wrote:
>&g
at I'd like to see is a way for multiple markup languages to
coexist and compete with each other on a level playing field, instead of
one being chosen as the winner.
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Fredrik Lundh wrote:
> Talin wrote:
>
>> Maybe instead of considering a match object to be a sequence, a match
>> object should be considered a map?
>
> sure, except for one small thing. from earlier in this thread:
>
> > Ka-Ping Yee wrote:
> >
>
st-style sequence that also has to
> support full slicing sounds like an utterly foolish consistency to me.
Maybe instead of considering a match object to be a sequence, a match
object should be considered a map? After all, we do have named, as well
as
Talin wrote:
> What I am doing right now is creating a new extension project using
> setuputils, and keeping notes on what I do. So for example, I start by
> creating the directory structure:
>
> mkdir myproject
> cd myproject
> mkdir src
> mkdir test
to come, which implies that such statements are
self-fulfilling prophesies. Which means that statements about whether a
particular language feature is pythonic are themselves pythonic.
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http
ot; names, simply because they are
obscure. Names that only make sense once you've gotten the joke may be
self-gratifying but not good HCI.
How about:
python -M install
Or maybe we could even lobby to get:
python --install
as a synonym of the above?
-- Talin
ybe this is something that we should be asking the LSB folks for
advice on?
>
> --
> Greg
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/opti
Martin v. Löwis wrote:
> Talin schrieb:
>> To that extent, it can be useful sometimes to have someone who is in the
>> process of learning how to use the system, and who is willing to
>> carefully analyze and write down their own experiences while doing so.
>
&g
Mike Orr wrote:
> On 11/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Talin schrieb:
>>> As far as rewriting it goes - I can only rewrite things that I understand.
>> So if you want this to change, you obviously need to understand the
>> en
tribution' in some of the function
> signatures? How do I use entry points, they look pretty complicated?"
> Some of these questions are multi-tool or are outside the scope of
> setuptools; some span both the Peak docs and the Python docs. People
>
Fredrik Lundh wrote:
> Talin wrote:
>
>> But it isn't just the docs that are at fault here - otherwise, I'd be
>> posting this on a different mailing list. It seems like the whole
>> architecture is 'diff'-based, a series of patches on top of pa
s confusing when we start talking about
"pure python" modules that have no C component - because we have all
this language that talks about compiling and installing and such, when
all that is really going on underneath is a plain old file copy.
-- Talin
___
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
relies on the GIL.
Nitpick: You have to remove all sharing of *mutable* objects. One day,
when we get "pure" GC with no refcounting, that will be a meaningful
distinction. :)
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
htt
better.
>
> regards
> Steve
The term used in many languages for this sort of operation is "combine".
(See .Net System.IO.Path for an example.) I kind of like the term - it
implies that you are mixing two paths together, but it doesn't imply
that the combination will be
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...?
Mike Orr wrote:
> I just saw the Path object thread ("PEP 355 status", Sept-
BJörn Lindqvist wrote:
> On 10/28/06, Talin <[EMAIL PROTECTED]> wrote:
>> BJörn Lindqvist wrote:
>> > I'd like to write a post mortem for PEP 355. But one important
>> > question that haven't been answered is if there is a possibility for a
>> >
friends, but they prefer a different
approach; And several of the responses sketch out some suggestions for
what that approach might be.
So what happens next?
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Greg Ewing wrote:
> Talin wrote:
>
>> That's true of textual paths in general - i.e. even on unix, textual
>> paths aren't guaranteed to be unique or exist.
>
> What I mean is that it's possible for two different
> files to have the same pathna
Greg Ewing wrote:
> Talin wrote:
>> (Actually, the OOP approach has a slight advantage in terms of the
>> amount of syntactic sugar available,
>
> Even if you don't use any operator overloading, there's
> still the advantage that an object provides a namespa
Phillip J. Eby wrote:
> At 09:49 AM 10/25/2006 -0700, Talin wrote:
>> Having done a path library myself (in C++, for our code base at work),
>> the trickiest part is getting the Windows path manipulations right, and
>> fitting them into a model that allows writing of p
Nick Coghlan wrote:
> Talin wrote:
>> Part 3: Does this mean that the current API cannot be improved?
>>
>> Certainly not! I think everyone (well, almost) agrees that there is
>> much room for improvement in the current APIs. They certainly need to
>> be refactor
Scott Dial wrote:
> [EMAIL PROTECTED] wrote:
>> Talin writes:
>> > (one additional postscript - One thing I would be interested in is
>> an > approach that unifies file paths and URLs so that there is a
>> consistent > locator scheme for any resource, wheth
[EMAIL PROTECTED] wrote:
> Talin writes:
> > (one additional postscript - One thing I would be interested in is an
> > approach that unifies file paths and URLs so that there is a consistent
> > locator scheme for any resource, whether they be in a filesystem, on a
>
(one additional postscript - One thing I would be interested in is an
approach that unifies file paths and URLs so that there is a consistent
locator scheme for any resource, whether they be in a filesystem, on a
web server, or stored in a zip file.)
-- Talin
be improved?
Certainly not! I think everyone (well, almost) agrees that there is much
room for improvement in the current APIs. They certainly need to be
refactored and recategorized.
But I don't think that the solution is to take all of the path-related
functions and drop them into a single class, or even a single module.
---
Anyway, I hope that (a) that answers your questions, and (b) isn't too
divergent from most people's views about Path.
-- Talin
___
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
lazy slices are *faster* on
> average, its overall effect on memory use in real-world Python is not
> yet known. Read on.
I wonder - how expensive would it be for the string slice to have a weak
reference, and 'normalize' the slice when the big string is collec
Anthony Baxter wrote:
> Thanks to the folks involved in this prcocess - I'm looking forward to
> getting
> the hell away from SF's bug tracker. :-)
Yes, let us know when the new tracker is up, I want to start using it :)
___
Python-Dev mailing list
Py
=detail&aid=1569040&group_id=5470&atid=305470
>
>
> Shall I close/delete that patch and submit a new patch with a more
> modern description? After all, there's not a lot of activity on the old
> patch page...
>
>
> Cheers,
>
>
> /larry/
>
> * As I recall, stringobject.c needs the trailing zero in exactly *one*
> place: when comparing two zero-le
an be deduced from looking at the code itself. And the reader shouldn't
have to read a bunch of redundant information which they can easily see
for themselves.
> I guess this is a long-winded way of saying, "me too".
>
> Skip
ditto.
-- Talin
___
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
ame companies use Lua for embedded scripting languages in
their games. (Console-based games in particular have strict memory
requirements, since there's no virtual memory on consoles.)
-- Talin
___
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
lassic class, but 'class Foo():'
would create a new-style class.
However, once it's released as 2.5 that will no longer be the case, as
people might start to use () to indicate a classic class. Oh well.
-- Talin
___
Python-Dev mail
d to get rid of the parentheses as well.
Is the result a new-style or classic-style class? It would be nice if
using the empty parens forced a new-style class...
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
is more work than doing it all in one
shot. However, I know from past experience that the trickiest part of
doing a pervasive change to a code base like this is just keeping track
of what parts have been migrated and what parts have not. Many times in
the past I've changed the definition of
process
Actually - can we make new-style classes the default, but allow a way to
switch to old-style classes if needed? Perhaps a command-line argument
to set the default back to old-style?
-- Talin
___
Python-Dev mailing list
Python-Dev@python.org
http
e,
I'm not sure that they all are.
For example, neither of the following statements blows up:
print t2.get_name.func_closure[0]
print object.__getattribute__( t2, '__dict__' )
Still, its perhaps a useful basis for experimentation.
-- Talin
_
y
print t1.name
print t2.get_name()
# This gets AttributeError because there's no such attribute
print t2.unk()
# These generate GuardException
print t2.set_name()
print t2.__dict__
print t2.__class__
print t2.name
--
-- Talin
_
chitecture.
Now, speaking from complete ignorance here, I might be way off base - it
may be that this matter is well in hand, perhaps on some other mailing
list. I don't know. In any case, I wanted to throw this out there...
-- Talin
___
Pytho
ttribute wrapper, returns that, otherwise
it fails.
(Although, I've often wished for Python to have a variant of __call__
that could be used to override individual methods, i.e.:
__call_method__( self, methodname, *args )
This would make the guard wr
the meaning to me. I suspect that
>>means one's ultimately as good (or as bad) as the rest.
>
>
> What's wrong with "nonlocal"? I don't think i've seen an argument
> against that one so far (from Talin or others).
Well, I just think that a fix for &
Talin wrote:
> Some alternatives:
>
> use x
> using x
> with x -- recycle a keyword?
> reuse x
> use extant x
> share x
> common x
> same x
> borrow x
> existing x
>
> Although, to be perfectly
Part of the reason why its so hard to name this feature is that it's
real name is something like "Hey, Python, you know that cool funky thing
you do with defining variables in the same scope as they are assigned?
Well, don't do that here."
-- Talin
___
e( path, perms ):
if perms == 'r':
# Trivial example, a real proxy would be more
# sophisticated, and probably configurable.
return protect( file( path, perms ),
methods=set('ope
he 'real' file
handle - in other words, replace the 'file-like object' wrapper with a
'config-like object' wrapper.
Merely passing the poisoned file handle to 'config' doesn't work,
because 'config' doesn't know how to safely handle
Brett Cannon wrote:
> On 7/6/06, Talin <[EMAIL PROTECTED]> wrote:
>> And if we can call it for every operation, then we don't have to spend
>> time hunting down all of the possible loopholes and ways in which 'file'
>> or other restricted objects might be
Brett Cannon wrote:
> On 7/5/06, Talin <[EMAIL PROTECTED]> wrote:
>> Transitioning from the checked to the unchecked state could only be done
>> via C code. So the 'file' wrapper, for example, would switch over to the
>> unchecked interpreter before calling th
ked state can call
methods on 'file' without blowing up.
So essentially, what I propose is to define a simple security primitive
- which essentially comes down to checking a single bit - and use that
as a basis to create more complex and subtle security mechanisms.
-- Talin
___
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
ally have no stake in this proposal, and I don't
intend to spend any time defending it other than to correct
misperceptions - however, I offer it as a potential starting point for
people who are interested in the whole lexical scoping issue. If someone
feels that this prop
nt x # Error, unassigned value
my x = 2
In the above example, even though the 'my' statement occurs after the
print, the scope created by the 'my' statement is in effect for the
entire function, although the actual *assignment* takes place after the
print. The reason fo
have your own version, you can
always override the 'my' statement with another 'my' statement:
my f = 1
def a():
my f = 2
a()
print f # prints '1'
The 'my' statement essentially changes the scopi
c )
Now we have two versions of the function, each having a different switch
dictionary.
Note that 'switch' is still usable without 'freeze', it just won't run
as fast. This means that the folks who are interested in a switch
statement purely for its
r a moment - the main point of the thread was the
idea that the dispatch table was built explicitly rather than
automatically - that instead of arguing over first-use vs.
function-definition, we let the user decide. I'm sure that my specific
proposal isn't the only way tha
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>
>>My version of this is to add to Python the notion of a simple
>>old-fashioned subroutine - that is, a function with no arguments and no
>>additional scope, which can be referred to by name. For example:
y disadvantage of this form is that the case values and the
associated code blocks are no longer co-located, which reduces some of
the expressive power of the switch.
Note that if you don't want to define a new keyword, an alternate syntax
would be 'def name:' with no argument braces, indicating that this is
not a function but a procedure.
-- Talin
___
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
accesses
the local variables of a function to be textually embedded within that
function, and you can't build a dispatch table outside of a function
that refers to code sections within a function.
In the interest of brevity, I'm going to cut it off here before I ramble
on too much long
#x27;m tempted to propose a way for the compiler to import static
definitions from outside the module ('static import'?) however I
recognize that this would greatly increase the fragility of Python,
since now you have the possibility tha
I'm sure I am not the first person to say this, but how about:
global x = 12
(In other words, declare a global and assign a value to it - or another
way of saying it is that the 'global' keyword acts as an assignment
modif
ctually, it might be simpler just to always reject local variables -- even
> at the top-level -- and be done with it.
I don't get what the problem is here. A switch constant should have
exactly the bahavior of a default value of a function parameter. We
don't seem to h
not one of the primary design goals of the language as I understand it.
My advice to people in this situation is to consider that perhaps some
level of translation between their syntax and Python syntax may be in
order. It would not be hard for the interactive interpreter to convert
instances of
x = y # Writes over the x defined in 'foo'
bar()
The idea is that 'bar' would share the same scope as 'foo'. To keep the
subroutine lightweight (i.e. just a single jump and return instruction
in the virtual machine) arguments would not be allowed.
-- Tali
[EMAIL PROTECTED] wrote:
> talin> Since you don't have the 'fall-through' behavior of C, I would
> talin> also assume that you could associate more than one value with a
> talin> case, i.e.:
>
> talin> case 'a', 'b
, but a
restricted one, and I am wondering if we could come up with a syntax
that avoids having a special suite.
Here's an (ugly) example, not meant as a serious proposal:
select (x) when 'a':
...
when 'b', 'c':
...
else:
...
The only real d
mple, I can envision a
desire that 'sys' would stay a top-level name, rather than 'rt.sys'.
Certain modules are so fundamental that they deserve IMHO to live in the
root namespace.
-- Talin
___
Python-Dev mailing list
Python-Dev@p
>
> Steve
I'd like to second Steve's point. I'm impressed by the thoroughness and
organization of the PEP.
As a general guideline, I've noticed that proposals which are purely
syntactic sugar are unlikely to be accepted unless there is some
additional benefit o
he controversies on that one
have quieted down; Virtually everyone seems in favor of the first part,
and you have already ruled in favor of the second part. So I am not sure
that there is anything more to discuss.
Perhaps I should go ahead and put 3102 on c.l.p at this point.
-- Talin
Guido van Rossum wrote:
> On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
>
>> I've updated PEP 3101 based on the feedback collected so far.
>
> [http://www.python.org/dev/peps/pep-3101/]
>
> I think this is a step in the right direction.
Cool, and thanks f
ters. Make up one rule and be consistant.
What would you suggest? I'd be interested in hearing what kinds of
ideas people have for fixing these problems.
-
-- Talin
___
Python-Dev mailing list
Py
Steven Bethard gmail.com> writes:
> I believe the proposal is taking advantage of the fact that '\{' is
> not interpreted as an escape sequence -- it is interpreted as a
> literal backslash followed by an open brace:
This is exac
".format(dict(name='Fred'))
I'm not opposed to the idea of adding item access, although I believe that
attribute access is also useful. In either case, its not terribly hard to
implement.
I'd like to hear what other people have to say on this issue.
-- Talin
__
I've updated PEP 3101 based on the feedback collected so far.
-
PEP: 3101
Title: Advanced String Formatting
Version: $Revision: 45928 $
Last-Modified: $Date: 2006-05-06 18:49:43 -0700 (Sat, 06 May 2006) $
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/
have a reasonable debate on the subject. I'd suggest that if you
really want to be heard (instead of merely having that "I'm right"
feeling) that you try a different approach.
-- Talin
___
Python-Dev mailing list
Python-Dev@pyth
Guido van Rossum python.org> writes:
> Sorry to bother the list -- talin, mail to you is bouncing:
Someone sent me mail? Cool! :)
Sorry about that, I'm in the process of migrating hosting providers, and I
forgot to add an email account for myself :) It should be better now, I'
hat than a
> restricted subset of the language -- especially if the syntax looks and
> works differently from real python.
The in-string syntax is limited deliberately for security reasons.
Allowing arbitrary executable code within a str
of items *in* an argument list.
>
> I grant that it makes sense as a derivation from "*ignore"-type
> solutions, but as a standalone syntax it feels off. How about
> something like:
>def compare(a, b; key=None):
I wanted the semicolon as well, but was overruled. The current
proposal is merely a summary of the output of the discussions
so far.
-- Talin
___
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
Thomas Wouters python.org> writes:
> Pfft, implementation is easy. I have the impression Talin wants to
implement it himself, but even if he doesn't, I'm sure I'll have a
free week somewhere in the next year and a half in which I can
implement it :) It's not that hard a
PEP: 3101
Title: Advanced String Formatting
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 16-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a new system for built-in string formatting
PEP: 3102
Title: Keyword-Only Arguments
Version: $Revision$
Last-Modified: $Date$
Author: Talin
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 22-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a change to the way that function arguments are
a matter of minutes.
As far as the "compatibility with tools" argument goes, I say, break em :)
Those tool programmers need a hobby anyway :)
-- Talin
___
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
er of that module, not the "os" module.
-- Talin
___
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
addresses this issue?
-- Talin
___
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
1 - 100 of 104 matches
Mail list logo
