Paul Moore wrote:
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a recommendation
in PEP 8 that such modules should have a global variable called
On Feb 5, 2012 5:36 PM, Steven Dapos;Aprano st...@pearwood.info wrote:
Paul Moore wrote:
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a
Terry Reedy wrote:
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a recommendation
in PEP 8 that such modules should have a global variable called PREVIEW, and
+1
On Feb 4, 2012 8:37 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 February 2012 11:25, Steven D'Aprano st...@pearwood.info wrote:
It strikes me that it would be helpful sometimes to programmatically
recognise preview modules in the std lib. Could we have a
recommendation
in PEP 8 that
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Benderskyeli...@gmail.com wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
Chris Withers wrote:
Every time I see things like the following I cry a little inside:
try:
try:
from py2stdliblocation import FooBar as Foo
except ImportError:
from py3stdliblocation import foo as Foo
except ImportError:
from pypilocation import Foo
The syntax is inelegant,
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed under Abandoned,
Woohoo! :)
___
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
On 1/29/2012 4:39 PM, Gregory P. Smith wrote:
An example of this working: ipaddr is ready to go in. It got the
eyeballs and API modifications while still a pypi library as a result
of the discussion around the time it was originally suggested as being
added. I or any other committers have
Maybe that's another example of waiting too long for the perfect
decision though. In the last ~12 months, ipaddr was downloaded at
least 11,000 times from its home
(http://code.google.com/p/ipaddr-py/downloads/list). There's been a
fair amount of changes over that time and a new release was put
On Sun, 29 Jan 2012 16:42:28 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Jan 29, 2012 at 1:29 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
I'm willing to go along with that (especially given your report of
On Tue, Jan 31, 2012 at 4:59 AM, Antoine Pitrou solip...@pitrou.net wrote:
It would be nice if that pronouncement or decision could outline the
steps required to include an experimental module in the stdlib, and
the steps required to move it from experimental to stable.
Actually, that's a good
On Fri, Jan 27, 2012 at 9:26 AM, Alex alex.gay...@gmail.com wrote:
Eli Bendersky eliben at gmail.com writes:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
On 29 January 2012 21:39, Gregory P. Smith g...@krypto.org wrote:
An example of this working: ipaddr is ready to go in. It got the
eyeballs and API modifications while still a pypi library as a result
of the discussion around the time it was originally suggested as being
added. I or any
On Jan 28, 2012, at 07:29 PM, Guido van Rossum wrote:
Finally, if you really want to put warnings in whenever an
experimental module is being used, make it a silent warning, like
SilentDeprecationWarning. That allows people to request more strict
warnings without unduly alarming the users of an
On Mon, Jan 30, 2012 at 8:44 AM, Barry Warsaw ba...@python.org wrote:
Nothing beats people beating on it heavily for years in production code to
shake things out. I often think a generic answer to did I get the API right
could be no, but it's okay :)
Heh, my answer to complaints about the
I think an advocacy of 3rd party modules would start with modules such as
ipaddr, requests, regex. Linking directly to them from the python core
documentation, while requesting they hold a successful moratorium in order
to be included in a later standard module release.
On Jan 30, 2012 10:47 AM,
On Sat, Jan 28, 2012 at 9:49 AM, Matt Joiner anacro...@gmail.com wrote:
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
+1. I'd much rather just use the module from PyPI.
It would be
+1. I'd much rather just use the module from PyPI.
It would be good to have a practical guide on how to manage the
transition from third-party to core library module though. A PEP with
a list of modules earmarked for upcoming inclusion in the standard
library (and which Python version
Nick Coghlan writes:
People need to remember there's another half to this equation: the
core dev side.
Why? There's nothing about it in the PEP.wink/
The reason *regex* specifically isn't in the stdlib already is
largely due to (perhaps excessive) concerns about the potential
On Sat, Jan 28, 2012 at 5:49 PM, Matt Joiner anacro...@gmail.com wrote:
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
People saying this: we KNOW this approach doesn't work in all
On Sat, Jan 28, 2012 at 6:38 PM, Stephen J. Turnbull step...@xemacs.org wrote:
I don't have an opinion on whether this is an argument for rejecting
the PEP or for rewriting it (specifically, seriously beefing up the
after trying it, maybe we won't want to maintain it rationale). I
also think
Wiadomość napisana przez Simon Cross w dniu 28 sty 2012, o godz. 08:58:
+1. I'd much rather just use the module from PyPI.
It would be good to have a practical guide on how to manage the
transition from third-party to core library module though. A PEP with
a list of modules earmarked for
On 28 January 2012 09:18, Nick Coghlan ncogh...@gmail.com wrote:
It's basically us saying to Python users We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into our build process, test suite and binary releases,
so you don't even
On 28 January 2012 01:48, Barry Warsaw ba...@python.org wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so get it from them.
On 1/28/2012 2:10 AM, Nick Coghlan wrote:
On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
Executive summary:
If the promise to remove the module from __preview__ is credible (ie,
strictly kept), then __preview__ will have a specific audience in
those who want
__preview__ would fall into this category as well). And yet I have
essentially no means of gaining access to any 3rd party modules,
whether they are packaged by the distro or obtained from PyPI. (And
build your own isn't an option in many cases, if only because a C
compiler may well not be
Hi,
Am 27.01.2012 um 18:26 schrieb Alex:
I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
instead of it's final destination directly because it needs feedback/possibly
changes. However, given the release cycle of the stdlib (~18 months), any
feedback it gets can't
On 28/01/2012 13:04, Paul Moore wrote:
On 28 January 2012 09:18, Nick Coghlanncogh...@gmail.com wrote:
It's basically us saying to Python users We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into our build process, test suite and
On 27/01/2012 22:54, Barry Warsaw wrote:
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsawba...@python.org wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API, and I think despite the caveats that
On 28/01/2012 05:09, Scott Dial wrote:
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so
On 28/01/2012 13:55, Matt Joiner wrote:
__preview__ would fall into this category as well). And yet I have
essentially no means of gaining access to any 3rd party modules,
whether they are packaged by the distro or obtained from PyPI. (And
build your own isn't an option in many cases, if only
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
Michael Foord writes:
Assuming the module is then promoted to the the standard library
proper in
release ``3.X+1``, it will be moved to a permanent location in the
library::
import example
And importing it
On Sat, 28 Jan 2012 02:49:40 -0500
Matt Joiner anacro...@gmail.com wrote:
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable.
That will probably never happen. pip install XXX is the best we
(python-dev and the community) can do. import
On Sat, 28 Jan 2012 00:09:13 -0500
Scott Dial scott+python-...@scottdial.com wrote:
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI,
well
then
On Sat, Jan 28, 2012 at 5:04 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 28 January 2012 09:18, Nick Coghlan ncogh...@gmail.com wrote:
It's basically us saying to Python users We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
So I do not support the __preview__ package. I think we're better off
flagging experimental modules in the docs than in their name. For the
specific case of the regex module, the best way to adoption may just
be to include it in the stdlib as
On Sat, 28 Jan 2012 13:14:36 -0500
Barry Warsaw ba...@python.org wrote:
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
So I do not support the __preview__ package. I think we're better off
flagging experimental modules in the docs than in their name. For the
specific case of the regex
Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 28 Jan 2012 13:14:36 -0500
Barry Warsaw ba...@python.org wrote:
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
So I do not support the __preview__ package. I think we're better
off
flagging experimental modules in the docs than in
Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit :
Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 28 Jan 2012 13:14:36 -0500
Barry Warsaw ba...@python.org wrote:
On Jan 28, 2012, at 09:15 AM, Guido van Rossum wrote:
So I do not support the __preview__ package. I think
Michael Foord wrote:
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
I think it's a bad idea to introduce a feature that's *supposed* to
break (in the sense of make a break, ie, change the normal pattern)
with every release and then try to avoid breaking (in the sense of
causing an unexpected
Antoine Pitrou solip...@pitrou.net wrote:
Le samedi 28 janvier 2012 à 10:46 -0800, Mike Meyer a écrit :
Antoine Pitrou solip...@pitrou.net wrote:
You will see people copying recipes found on the internet without
knowing that they rely on unstable APIs.
How. About doing them the way we do
You're proposing that new experimental modules spit warnings when you
use them?
To be explicit, when the system loada them.
There are many reasons to import a module, such as viewing its
documentation. And the warning will trigger if the import happens in
non-user code, such as a library;
On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou solip...@pitrou.net wrote:
There are many reasons to import a module, such as viewing its
documentation. And the warning will trigger if the import happens in
non-user code, such as a library; or when there is a fallback for the
module not being
Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou solip...@pitrou.net wrote:
There are many reasons to import a module, such as viewing its
documentation. And the warning will trigger if the import happens in
non-user code, such as
On Sat, Jan 28, 2012 at 4:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le samedi 28 janvier 2012 à 16:03 -0700, Eric Snow a écrit :
On Sat, Jan 28, 2012 at 3:02 PM, Antoine Pitrou solip...@pitrou.net wrote:
There are many reasons to import a module, such as viewing its
documentation. And
On 1/28/2012 3:55 AM, Nick Coghlan wrote:
I am currently -something on the proposal as it because it will surely
create a lot of hassles and because I do not think it is necessary the
best solution to the motivating concerns.
Don't consider this PEP a purely theoretical proposal, because it
On Sun, Jan 29, 2012 at 3:15 AM, Guido van Rossum gu...@python.org wrote:
Hm. You could do this just as well without a __preview__ package. You
just flag the module as experimental in the docs and get on with your
life.
We have some experience with this in Google App Engine. We used to use
a
On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
I'm willing to go along with that (especially given your report of
AppEngine's experience with the labs namespace).
Can we class this as a pronouncement on PEP 408? That is, No to
adding a __preview__ namespace, but yes
+0. I think the idea is right, and will help to get good quality
modules in at a faster rate. However it is compensating for a lack of
interface and packaging standardization in the 3rd party module world.
___
Python-Dev mailing list
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for any upgrade or downgrade of
python version.
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky eli...@gmail.com wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org/dev/peps/pep-0408/
A
On 27/01/2012 14:37, Philippe Fremy wrote:
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Benderskyeli...@gmail.com wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
2012/1/27 Eli Bendersky eli...@gmail.com:
Criteria for graduation
-
I think you also need Criteria for being placed in __preview__. Do
we just toss everything someone suggests in?
--
Regards,
Benjamin
___
Python-Dev mailing
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson - json):
try:
from __preview__ import thing
except ImportError:
import thing
So no need
On 27/01/2012 15:34, Benjamin Peterson wrote:
2012/1/27 Eli Benderskyeli...@gmail.com:
Criteria for graduation
-
I think you also need Criteria for being placed in __preview__. Do
we just toss everything someone suggests in?
And given that permanently deleting
On 27/01/2012 15:35, Matt Joiner wrote:
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson - json):
try:
from __preview__ import thing
except
On 27/01/2012 16:25, Michael Foord wrote:
On 27/01/2012 14:37, Philippe Fremy wrote:
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of
Hello Philippe,
On Fri, 27 Jan 2012 17:09:08 +0100
Philippe Fremy p...@freehackers.org wrote:
According to the PEP, the interface may change betweeen __preview__ and
final inclusion in stdlib. It would be unwise as a developer to assume
that a program written for the preview version will
Assuming the module is then promoted to the the standard library proper in
release ``3.X+1``, it will be moved to a permanent location in the library::
import example
And importing it from ``__preview__`` will no longer work.
Why not leave it accessible through __preview__ too?
I
Something along the lines of :
if sys.version_info[:2] == (3, X):
from __preview__ import example
else:
raise ImportError( 'Package example is only available as preview in
Python version 3.X. Please check the documentation of your version of
Python to see if and how you can
On Fri, Jan 27, 2012 at 17:34, Benjamin Peterson benja...@python.org wrote:
2012/1/27 Eli Bendersky eli...@gmail.com:
Criteria for graduation
-
I think you also need Criteria for being placed in __preview__. Do
we just toss everything someone suggests in?
I hoped to
Eli Bendersky eliben at gmail.com writes:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org/dev/peps/pep-0408/
[1]
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT expected to
have a forward-compatible, stable, API. This is a
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial and wrong.
Since thing and __preview__.thing
On Jan 27, 2012, at 05:26 PM, Alex wrote:
I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
instead of it's final destination directly because it needs feedback/possibly
changes. However, given the release cycle of the stdlib (~18 months), any
feedback it gets can't be
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw ba...@python.org wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API, and I think despite the caveats that are explicit in
__preview__, Python will just catch tons of grief from users and haters about
On 27 January 2012 21:48, Antoine Pitrou solip...@pitrou.net wrote:
Well, obviously __preview__ is not for the most conservative users. I
think the name clearly conveys the idea that you are trying out
something which is not in its definitive state, doesn't it?
Agreed. But that in turn implies
On Jan 27, 2012, at 10:02 PM, Paul Moore wrote:
Agreed entirely. We need a way to signal somehow that a module is
being seriously considered for stdlib inclusion. That *would* result
in more uptake, and hence more testing and feedback.
I'm just not convinced that's a message that we can clearly
On Fri, 27 Jan 2012 17:54:14 -0500
Barry Warsaw ba...@python.org wrote:
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw ba...@python.org wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API,
On Fri, Jan 27, 2012 at 11:48 PM, Matt Joiner anacro...@gmail.com wrote:
+0. I think the idea is right, and will help to get good quality
modules in at a faster rate. However it is compensating for a lack of
interface and packaging standardization in the 3rd party module world.
No, it really
n Sat, Jan 28, 2012 at 3:26 AM, Alex alex.gay...@gmail.com wrote:
I think a significantly healthier process (in terms of maximizing feedback and
getting something into it's best shape) is to let a project evolve naturally
on
PyPi and in the ecosystem, give feedback to it from an inclusion
On Sat, Jan 28, 2012 at 6:43 AM, Steven D'Aprano st...@pearwood.info wrote:
This PEP only makes sense if we assume that __preview__.spam and spam *will*
be different, even if only in minor ways, and that there might not even be a
spam. There should be no expectation that every __preview__
On Sat, Jan 28, 2012 at 8:54 AM, Barry Warsaw ba...@python.org wrote:
I think the OS vendor problem is easier with an application that uses some
PyPI package, because I can always make that package available to the
application by pulling in the version I care about. It's harder if a newer,
On Jan 28, 2012, at 11:37 AM, Nick Coghlan wrote:
Then the stdlib docs for that module (while it is in __preview__)
would say If you are able to easily use third party packages, package
X offers this API for multiple Python versions with stronger API
stability guarantees. This preview version of
On Jan 28, 2012, at 11:27 AM, Nick Coghlan wrote:
* for an intranet web service deployment where due diligence adds
significant overhead to any use of third party packages
Which really means that *we* are assuming the responsibility for this due
diligence. And of course, we should not add
On Jan 28, 2012, at 11:13 AM, Nick Coghlan wrote:
Really, regex is the *reason* this PEP exists: we *know* we need to
either replace or seriously enhance re (since its Unicode handling
isn't up to scratch), but we're only *pretty sure* adding regex to
the stdlib is the right answer. Adding
On 27/01/2012 20:43, Steven D'Aprano wrote:
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT
expected to have a
Michael Foord wrote:
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it
No, potentially wrong in cases where the APIs are different. Even with the
try...except ImportError dance around StringIO / cStringIO there are some
API differences. But for a lot of use cases it works fine (simplejson and
json aren't *identical*, but it works for most people).
Okay,
Executive summary:
If the promise to remove the module from __preview__ is credible (ie,
strictly kept), then __preview__ will have a specific audience in
those who want the stdlib candidate code and are willing to deal with
a certain amount of instability in that code.
(Whether that audience is
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so get it from them.
That is my thought
Eli Bendersky writes:
My point is that if our users accept *this*, in the stable stdlib, I
see no reason they won't accept the same happening between __preview__
and a graduated module, when they (hopefully) understand the intention
of __preview__.
If it doesn't happen with sufficiently
On Sat, Jan 28, 2012 at 07:41, Stephen J. Turnbull step...@xemacs.org wrote:
Eli Bendersky writes:
My point is that if our users accept *this*, in the stable stdlib, I
see no reason they won't accept the same happening between __preview__
and a graduated module, when they (hopefully)
On Sat, Jan 28, 2012 at 11:48 AM, Barry Warsaw ba...@python.org wrote:
Would it be acceptable then for a distro to disable __preview__ or empty it
out?
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package
On Sat, Jan 28, 2012 at 3:22 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Executive summary:
If the promise to remove the module from __preview__ is credible (ie,
strictly kept), then __preview__ will have a specific audience in
those who want the stdlib candidate code and are willing to
On Sat, Jan 28, 2012 at 4:37 PM, Nick Coghlan ncogh...@gmail.com wrote:
I think that's an excellent idea - in that case, the distro vendor is
taking over the due diligence responsibilities, which are the main
point of __preview__.
Heh, contradicted myself in my next email. python-dev handling
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com wrote:
I think a significantly healthier process (in terms of maximizing feedback and
getting something into it's best shape) is to let a project evolve naturally
on
PyPi and in the ecosystem, give feedback to it from an inclusion
FWIW I'm now -1 for this idea. Stronger integration with PyPI and
packaging systems is much preferable. Python core public releases are
no place for testing.
On Sat, Jan 28, 2012 at 2:42 AM, Matt Joiner anacro...@gmail.com wrote:
On Fri, Jan 27, 2012 at 12:26 PM, Alex alex.gay...@gmail.com
91 matches
Mail list logo
