> Sorry to revive this thread, but mktemp() is very useful when the file is
> meant
> to be created by another application (e.g. launched by subprocess, but it
> could
> even be a daemon running under a different user). For example if I have a
> processing chain to converts a PDF to a temporary J
Greg Ewing writes:
> [EMAIL PROTECTED] wrote:
> > I guess we're going to have to agree to disagree. I find hiding
> directories
> > which contain executable code extremely non-obvious.
>
> I'm worried by this too. I don't like the idea of putting
> large and important things in hidden d
-On [20080507 04:06], Tom Pinckney ([EMAIL PROTECTED]) wrote:
>While in theory UTF-8 is not a standard, sites like Last.fm, Facebook and
>Wikipedia seem to have embraced it (as have pretty much all other major web
>sites). As with HTML, there is what the standard says and what the actual
>browse
> Thanks for any thoughts on this,
The proper way to implement this would be IRIs (RFC 3987),
in particular section 3.1. This is not as simple as just
encoding it as UTF-8, as you might have to apply IDNA to
the host part.
Code doing so just hasn't been contributed yet.
Regards,
Martin
_
>> Check out http://openid-provider.appspot.com/
>>
>> Apparently it was created by your colleague Ryan Barrett. :)
I found that to be of limited use. If I use my proper gmail account
([EMAIL PROTECTED]), I managed to log into the OpenID directory,
but not, say, into SourceForge (probably becaus
Hi,
While trying to use urllib in python 2.5.1 to HTTP GET content from
various web sites, I've run into a problem with urllib.quote
(and .quote_plus): they don't accept unicode strings.
I see that this is an issue that has been discussed before:
see this thread:
http://mail.pytho
Greg Ewing schrieb:
> Guido van Rossum wrote:
>> The location will be somewhere under ~/.local
>> for Unix/Linux/OS X,
>
> Can I just put in a plea for this to be somewhere
> under ~/Library on OSX, and not hidden?
>
> MacOSX already has clear conventions for this sort
> of thing -- there's no ne
I just checked in Misc/TextMate/Python-Dev.tmbundle for those of you
use TextMate. I have been using this bundle for a while and I figured
others could use it.
Usage tends to expect that you have opened a project from the
top-level directory of a Python checkout. There is support to run the
Makefi
Guido van Rossum wrote:
The location will be somewhere under ~/.local
for Unix/Linux/OS X,
Can I just put in a plea for this to be somewhere
under ~/Library on OSX, and not hidden?
MacOSX already has clear conventions for this sort
of thing -- there's no need to use a dot-name there.
--
Greg
Steve Holden wrote:
If you want it visible, make a visible symbolic link!
I have to know it's there first. The idea of an installer
deliberately hiding stuff from me in a very unconventional
and non-obvious way makes me uncomfortable.
--
Greg
___
Py
[EMAIL PROTECTED] wrote:
> I guess we're going to have to agree to disagree. I find hiding directories
> which contain executable code extremely non-obvious.
I'm worried by this too. I don't like the idea of putting
large and important things in hidden directories automatically
without being tol
alexandre.vassalotti schrieb:
> Author: alexandre.vassalotti
> Date: Tue May 6 21:48:38 2008
> New Revision: 62778
>
> Log:
> Added fast alternate io.BytesIO implementation and its test suite.
> Removed old test suite for StringIO.
> Modified truncate() to imply a seek to given argument value.
T
Barry Warsaw schrieb:
> Very awesome Christian! I'm psyched for this to get into the last alpha
> releases, which I remind everyone happens tomorrow. Plan on svn tree
> freeze at approximately 6pm EDT (2200 UTC).
Thanks Barry! Also thanks to Glyph, Nick and all the other people that
stepped in d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 6, 2008, at 6:38 PM, Christian Heimes wrote:
Guido has accepted my user site directory PEP today.
http://python.org/dev/peps/pep-0370/
I'm about the merge the code. But first I like to let you know some
things and get your opinion.
Very aw
Dear fellow Pythonistas!
Guido has accepted my user site directory PEP today.
http://python.org/dev/peps/pep-0370/
I'm about the merge the code. But first I like to let you know some
things and get your opinion.
The location of the user site-package directory stays as written in my
PEP. The mast
Tristan Seligmann wrote:
The correct way to do this is to create a temporary directory, and then
generate a filename underneath that directory to use.
Yes, otherwise you can get bitten by the race condition
that's the reason for mktemp being deprecated.
--
Greg
___
Jeroen Ruigrok van der Werven wrote:
Is it a reference to Gerrit Rietveld (Dutch architect and furniture
designer)? I guess the architect part would make sense for a code review
tool. :)
According to Wikipedia, he was also a friend of Mondrian
and incorporated some of Mondrian's ideas into his
Hi Everybody.
My name is Robert Schuppenies and I also got accepted for this years
Google Summer of Code. I will be working on the Python Core with the
Memory Usage Profiler project and my mentor will be Martin von
Löwis. I am very happy that I got selected and look forward to work
on my project.
On Tue, May 6, 2008 at 11:43 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I just made another attempt to use ctypes to wrap a library, and am
> facing the same problem I had the last time: the documentation doesn't
> really work. I'm wondering if we have any projects underway to
> re-write it
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Tue, May 6, 2008 at 10:41 AM, Alexander Michael <[EMAIL PROTECTED]>
wrote:
| > Was it also a coincidence that Mondrian and Rietveld were both members
| > of the De Stijl movement? If so, a very nice one!
|
| No
On Tue, May 6, 2008 at 10:41 AM, Alexander Michael <[EMAIL PROTECTED]> wrote:
> Was it also a coincidence that Mondrian and Rietveld were both members
> of the De Stijl movement? If so, a very nice one!
No, that's my naming scheme. :-)
--
--Guido van Rossum (home page: http://www.python.org/~g
On Tue, May 6, 2008 at 1:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Tue, May 6, 2008 at 12:51 AM, Jeroen Ruigrok van der Werven
> <[EMAIL PROTECTED]> wrote:
> > -On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote:
> > > http://code.google.com/p/rietveld/source/browse
On Tue, May 6, 2008 at 12:51 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> -On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote:
> > http://code.google.com/p/rietveld/source/browse
>
> Is it a reference to Gerrit Rietveld (Dutch architect and furniture
> designer)?
On Tue, May 6, 2008 at 12:48 AM, Jeroen Ruigrok van der Werven wrote:
> -On [20080505 18:28], Guido van Rossum ([EMAIL PROTECTED]) wrote:
> >- AppEngine has a built-in API for dealing with Google Accounts, but
> >not for OpenID
> >
> >- Apparently OpenID requires some crypto that would be slow
On Tue, May 6, 2008 at 4:19 AM, Tristan Seligmann
<[EMAIL PROTECTED]> wrote:
> * Antoine Pitrou <[EMAIL PROTECTED]> [2008-05-06 10:47:23 +]:
> > Sorry to revive this thread, but mktemp() is very useful when the file is
> meant
> > to be created by another application (e.g. launched by subpro
All,
I've accepted PEP 370, Christian Heimes's proposal to add a per-user
site-package directory. The location will be somewhere under ~/.local
for Unix/Linux/OS X, and %APPDATA%/Python for Windows (per the
original proposal in the PEP).
Congratulations Christian, and thanks for championing this.
I just made another attempt to use ctypes to wrap a library, and am
facing the same problem I had the last time: the documentation doesn't
really work. I'm wondering if we have any projects underway to
re-write it?
Bill
___
Python-Dev mailing list
Pyth
>> /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local?
Alec> Because unlike a home directory, users don't frequently perform
Alec> directory listings or tab completion of /usr/. For a frequently
Alec> used personal directory one wants the minimum of noise.
I
On Tue, May 6, 2008 at 7:37 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> If you want it visible, make a visible symbolic link!
Note that the point is moot, since I'm going to accept Christian's
PEP, i.e. ~/.local, but this argument "you can make it visible
yourself" is bogus. The point of visibi
On Tue, May 6, 2008 at 8:11 AM, Alec Thomas <[EMAIL PROTECTED]> wrote:
> Python would not be unique. Mozilla/Firefox does exactly this, putting
> per-user plugins in ~/.mozilla.
Note that this is moot since I'm going to accept the PEP as it stands
(i.e. ~/.local) but I want to point out somethin
I'm not sure I understand the problem exactly. If we have one pass
converting the concrete syntax to the AST, we can mark functions as
generators as part of that pass. In a later pass, you can remove the
unreachable code.
Jeremy
On Sat, May 3, 2008 at 12:51 AM, Thomas Lee <[EMAIL PROTECTED]> wr
On Fri, May 2, 2008 at 1:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Martin v. Löwis wrote:
> >>> This leaves us with a few options:
> >>>
> >>
> >> 5. Reuse/Abuse Num(object) for arbitrary constants.
> >>AFAICT, this should work out of the box.
> >>
> >>
On Fri, 02 May 2008 00:03:24 - [EMAIL PROTECTED] wrote:
> On 11:45 pm, [EMAIL PROTECTED] wrote:
> >I like this, except one issue: I really don't like the .local
> >directory. I don't see any compelling reason why this needs to be
> >~/.local/lib/ -- IMO it should just be ~/lib/. There's no nee
> > /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local?
>
> Because unlike a home directory, users don't frequently perform
> directory listings or tab completion of /usr/. For a frequently used
> personal directory one wants the minimum of noise.
Glad someone around here kn
2008/5/7 <[EMAIL PROTECTED]>:
>
> Alec> FWIW my vote is for ~/.python. ~/.local comes in a distant second
> Alec> due to non-obviousness and ~/Python is several light years beyond
> Alec> that.
>
> I guess we're going to have to agree to disagree. I find hiding directories
> which c
Alec> FWIW my vote is for ~/.python. ~/.local comes in a distant second
Alec> due to non-obviousness and ~/Python is several light years beyond
Alec> that.
I guess we're going to have to agree to disagree. I find hiding directories
which contain executable code extremely non-obvious.
Alec Thomas wrote:
FWIW my vote is for ~/.python. ~/.local comes in a distant second due
to non-obviousness and ~/Python is several light years beyond that.
I think if the obviousness (or lack thereof) of the chosen directory
name ever really matters to anyone, we did it wrong. After all, unle
2008/5/6 Barry Warsaw <[EMAIL PROTECTED]>:
> On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote:
> > Am I the only guy who finds software that insists on visible, fixed files
> in my home directory rude? vmware, for example, wants a "~/vmware"
> directory, but pretty much every other application
* Antoine Pitrou <[EMAIL PROTECTED]> [2008-05-06 10:47:23 +]:
> pobox.com> writes:
> >
> > Back in r29829, Guido commented out the security hole warning for
> > tempfile.mktemp:
> >
> [...]
> >
> > Comment out the warnings about mktemp(). These are too annoying, and
> > often unav
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote:
Am I the only guy who finds software that insists on visible, fixed
files in my home directory rude? vmware, for example, wants a "~/
vmware" directory, but pretty much every other application
pobox.com> writes:
>
> Back in r29829, Guido commented out the security hole warning for
> tempfile.mktemp:
>
[...]
>
> Comment out the warnings about mktemp(). These are too annoying, and
> often unavoidable.
>
> Any thought about whether this warning should be restored? We're 5+ ye
-On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote:
> http://code.google.com/p/rietveld/source/browse
Is it a reference to Gerrit Rietveld (Dutch architect and furniture
designer)? I guess the architect part would make sense for a code review
tool. :)
--
Jeroen Ruigrok van der Wer
-On [20080505 18:28], Guido van Rossum ([EMAIL PROTECTED]) wrote:
>- AppEngine has a built-in API for dealing with Google Accounts, but
>not for OpenID
>
>- Apparently OpenID requires some crypto that would be slow without
>additional API support
>
>- I'm not personally familiar with OpenID
Check
43 matches
Mail list logo
