On Fri, 4 May 2012 13:29:14 +0100
Michael Foord wrote:
>
> On 4 May 2012, at 09:44, Vinay Sajip wrote:
>
> > IIUC, the program name of the Python executable is set to whatever argv[0]
> > is.
> > Is there a reason for this, rather than using one of the various OS-specific
> > APIs [1] for getti
On Fri, 4 May 2012 08:44:25 + (UTC)
Vinay Sajip wrote:
> IIUC, the program name of the Python executable is set to whatever argv[0] is.
> Is there a reason for this, rather than using one of the various OS-specific
> APIs [1] for getting the name of the running executable? The reason I ask is
On Fri, 4 May 2012 13:21:17 +0800
Senthil Kumaran wrote:
> On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou wrote:
> > Daily code coverage builds would be nice, but that's probably beyond
> > what the current infrastructure can offer. It would be nice if someone
> >
Hello,
On Fri, 04 May 2012 14:07:28 -0400
"Edward C. Jones" wrote:
> Filelist of package libbz2-dev in wheezy of architecture amd64
>
> /usr/include/bzlib.h
> /usr/lib/x86_64-linux-gnu/libbz2.a
> /usr/lib/x86_64-linux-gnu/libbz2.so
> /usr/share/doc/libbz2-dev
setup.py probably doesn't search i
Hi,
On Fri, 04 May 2012 14:49:03 -0600
Carl Meyer wrote:
>
> 3) Symlink the interpreter rather than copying. I include this here for
> the sake of completeness, but it's already been rejected due to
> significant problems on older Windows' and OS X.
Perhaps symlinking could be used at least
On Sat, 05 May 2012 15:31:24 +0200
Christian Heimes wrote:
> Am 05.05.2012 12:36, schrieb Antoine Pitrou:
> >
> > Hello,
> >
> > On Fri, 04 May 2012 14:07:28 -0400
> > "Edward C. Jones" wrote:
> >> Filelist of package libbz2-dev in wheezy
On Sat, 05 May 2012 16:04:40 +0200
Christian Heimes wrote:
> Am 05.05.2012 15:39, schrieb Antoine Pitrou:
> > On Sat, 05 May 2012 15:31:24 +0200
> > Christian Heimes wrote:
> >> Am 05.05.2012 12:36, schrieb Antoine Pitrou:
> >>>
> >>> Hello
On Sun, 6 May 2012 15:08:52 +1000
Nick Coghlan wrote:
>
> Agreed we should have a new header field to record the BDFL delegate,
> but I think I'll go with BDFL-Delegate rather than PEP-Czar.
+1 for overthrowing czars!
Regards
Antoine.
___
Python-De
On Sun, 6 May 2012 16:45:32 +1000
Nick Coghlan wrote:
>
> For the moment, I suggest leaving your email address out of this
> field. The email obfuscation is applied on a field-by-field basis, and
> the formatter for reStructuredText PEPs actually lives in the docutils
> upstream rather than being
On Sun, 06 May 2012 17:56:55 +0200
richard.oudkerk wrote:
> http://hg.python.org/cpython/rev/b4a1d9287780
> changeset: 76800:b4a1d9287780
> user:Richard Oudkerk
> date:Sun May 06 16:45:02 2012 +0100
> summary:
> Make AcquirerProxy.acquire() support timeout argument
Should it
On Sun, 06 May 2012 18:58:10 +0100
shibturn wrote:
> On 06/05/2012 5:07pm, Antoine Pitrou wrote:
> > On Sun, 06 May 2012 17:56:55 +0200
> >> summary:
> >>Make AcquirerProxy.acquire() support timeout argument
> >
> > Should it have a Misc/NEWS entry? (
On Mon, 7 May 2012 12:35:27 +0100
Mark Dickinson wrote:
>
> Hmm. Very clever, but it's not obvious that that overflow check is
> mathematically sound. As it turns out, the maths works provided that
> PY_SSIZE_T_MAX isn't congruent to 4 modulo 5; since PY_SSIZE_T_MAX
> will almost always be one
Hello,
I guess a long time ago, threading support in operating systems wasn't
very widespread, but these days all our supported platforms have it.
Is it still useful for production purposes to configure
--without-threads? Do people use this option for something else than
curiosity of mind?
Regar
Hello,
On Mon, 07 May 2012 16:42:50 -0400
"Edward C. Jones" wrote:
> I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
> and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
> with python3.2 (and 2.6 and 2.7). I installed the Debian package
> pytho
On Tue, 8 May 2012 19:40:32 +0200
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > I guess a long time ago, threading support in operating systems wasn't
> > very widespread, but these days all our supported platforms have it.
> > Is it still useful for produc
On Wed, 9 May 2012 11:26:29 +0200
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > > _decimal is about 12% faster without threads, because the expensive
> > > thread local context can be disabled.
> >
> > If you cached the last thread id along with the correspond
On Wed, 9 May 2012 10:44:59 -0400
Brett Cannon wrote:
>
> > I wish there was a builtin class
> >
> > class record:
> >pass
> >
> > which can be used to create objects which have only attributes
> > and no methods.
>
>
> I have heard this request now a bazillion times over the ye
On Thu, 10 May 2012 11:33:14 +1000
Nick Coghlan wrote:
>
> The original concern (that sys.implementation may differ in length
> across implementations) has been eliminated by moving all
> implementation specific values into sys.implementation.metadata.
Uh. It's scary the kind of things people so
On Thu, 10 May 2012 20:23:08 +0200
Stefan Krah wrote:
> Antoine Pitrou wrote:
> > On Wed, 9 May 2012 11:26:29 +0200
> > Stefan Krah wrote:
> > > Antoine Pitrou wrote:
> > > > > _decimal is about 12% faster without threads, because the expensive
> &g
On Sun, 13 May 2012 14:02:50 +0300
anatoly techtonik wrote:
> There is fear and uncertainty in this pull request to PyPI -
> https://bitbucket.org/techtonik/pypi-techtonik/changeset/5396f8c60d49#comment-18915
> - which is about that writing to stderr _might_ break things in WSGI
> applications.
>
On Sun, 13 May 2012 19:53:27 +0200
charles-francois.natali wrote:
>
> +This module also provides the following helper function:
> +
> +.. function:: secure_compare(a, b)
[...]
You need a versionadded tag.
Regards
Antoine.
___
Python-Dev mailing li
Hello all,
We still need 64-bit Windows buildbots to test for regressions.
Otherwise we might let regressions slip through, since few people seem
to run the test suite under Windows at home.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@p
On Fri, 18 May 2012 23:16:09 +1000
Nick Coghlan wrote:
> I know you fixed the deadlock problem, but the warnings about shutdown
> misbehaviour are still valid.
Do we have a reproducer? It should have been fixed by
http://bugs.python.org/issue1856.
Regards
Antoine.
___
On Sun, 20 May 2012 10:31:01 +0200
nick.coghlan wrote:
> +
> + .. impl-detail::
> +
> + CPython uses ``hash(id(x))`` as the default hash for class instances.
This isn't true:
>>> class C: pass
...
>>> c = C()
>>> hash(c)
619973
>>> id(c)
9919568
>>> hash(id(c))
9919568
id(...) always h
On Sun, 20 May 2012 18:51:27 +1000
Nick Coghlan wrote:
> PEP 3135 defines the new zero-argument form of super() as implicitly
> equivalent to super(__class__, ), and up until 3.2 has
> behaved accordingly: if you accessed __class__ from inside a method,
> you would receive a reference to the lexic
On Sun, 20 May 2012 13:18:29 -0400
Terry Reedy wrote:
> > +
> > +"""
> > +if version:
>
> if version is not None: ??
> Do you really want to silently ignore *every* null value, like '' or []?
The goal is probably to have "midnight" mean "auto-detect the address
family" ;-)
cheers
Antoi
On Mon, 21 May 2012 14:28:06 +1000
Nick Coghlan wrote:
> On Mon, May 21, 2012 at 11:23 AM, Guido van Rossum wrote:
> > I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org.
>
> Rather than a new subdomain, I'd prefer to see a discreet
> "documentation version" CSS widget,
On Mon, 21 May 2012 12:03:31 -0400
Terry Reedy wrote:
> On 5/21/2012 3:24 AM, Nick Coghlan wrote:
>
> > docs.python.org/latest
> > docs.python.org/dev
> > docs.python.org/3.2
> > docs.python.org/3.1
> > docs.python.org/2.7
> > docs.python.org/2.6
> > etc...
>
> This looks great except for 'lates
On Thu, 24 May 2012 12:11:58 -0700
Daniel Farina wrote:
>
> Finally, what's especially strange is that I had gone a very long time
> running this exact version of Python, libraries, and application quite
> frequently: it suddenly started cropping up a little while ago (maybe
> a few weeks).
Do y
On Fri, 25 May 2012 18:57:57 +0200
Georg Brandl wrote:
> Am 25.05.2012 07:54, schrieb benjamin.peterson:
> > http://hg.python.org/cpython/rev/a47d32a28662
> > changeset: 77129:a47d32a28662
> > user:Benjamin Peterson
> > date:Thu May 24 22:54:15 2012 -0700
> > summary:
> > sim
On Fri, 25 May 2012 10:21:39 -0700
Ethan Furman wrote:
> I'd like to make a slight doc change for weakref to state (more or less):
>
> weakrefs are not invalidated when the strong refs
> are gone, but rather when garbage collection
> reclaims the object
>
> Should this be accurate fo
On Sat, 26 May 2012 04:48:49 +0200
vinay.sajip wrote:
> +_sys_home = getattr(sys, '_home', None)
> +if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> +_sys_home = os.path.dirname(_sys_home)
What about pcbuild/amd64? Does this work on 64-bit builds?
> +_sys_home =
Hello,
In http://bugs.python.org/issue14837 I have attached a proof-of-concept
patch to improve the exceptions raised by the ssl module when OpenSSL
signals an error. The current situation is quite dismal, since you get
a sometimes cryptic error message with no viable opportunities for
programmat
On Sat, 26 May 2012 21:39:36 +0200
vinay.sajip wrote:
> return False
> _sys_home = getattr(sys, '_home', None)
> -if _sys_home and os.name == 'nt' and _sys_home.lower().endswith('pcbuild'):
> +if _sys_home and os.name == 'nt' and \
> +_sys_home.lower().endswith(('pcbuild', 'pcbuild\\amd6
On Sat, 26 May 2012 17:44:08 -0400
Terry Reedy wrote:
> > Traceback (most recent call last):
> > [...]
> > ssl.SSLError: [Errno 5] [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> > verify failed (_ssl.c:494) [88296 refs]
>
> Repeating the same reason in upper and lower case is unhelpful noise.
>
On Sat, 26 May 2012 19:31:55 -0700
"Gregory P. Smith" wrote:
>
> There is a long term caveat to the overall approach: It still leaves the
> exception details being OpenSSL specific. If someone wants to ditch
> OpenSSL and use something else such as NSS (for example) in a future _ssl
> implementa
On Sun, 27 May 2012 12:00:57 +1000
Cameron Simpson wrote:
> On 26May2012 21:28, Antoine Pitrou wrote:
> | Not only does the error string contain more valuable information (the
> | mnemonics "SSL" and "CERTIFICATE_VERIFY_FAILED" indicate, respectively,
> | in wh
On Sun, 27 May 2012 10:13:17 +0200
mar...@v.loewis.de wrote:
> > Nasty! Perhaps freeze_importlib.py could be rewritten in C, so
> > importlib could be recompiled when the compiler changes?
>
> Or we support bootstrapping from the source file, e.g. with an
> environment variable BOOTSTRAP_PY which
On Mon, 28 May 2012 17:25:10 + (UTC)
Vinay Sajip wrote:
>
> The foo.exe file is just a copy of a stock launcher executable which finds its
> name from the C argv[0], and based in that name (foo in this case), invokes
> foo-script.py or foo-script.pyw with the appropriate Python interpreter.
On Mon, 28 May 2012 19:37:55 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Regardless of what the executable is or does, its source code must be
> > included somewhere in the Python source tree (and, preferably, there
> > should be a si
On Mon, 28 May 2012 21:23:50 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Not necessarily, but OTOH, it is not really standard procedure to
> > commit half-finished patches.
>
> I didn't want to miss the window for the upco
Le 03/06/2012 06:01, Benjamin Peterson a écrit :
2012/6/2:
results for d9b7399d9e45 on branch "default"
test_smtplib leaked [154, 154, 154] references, sum=462
Can other people reproduce this one? I can't.
$ ./python -m test -R 3:3 -uall test_smt
Le 05/06/2012 19:21, Alexander Belopolsky a écrit :
with timezone.utc added to datetime module
already the cost of supplying tzinfo to UTC datetime objects is low.
This is nice when your datetime objects are freshly created. It is not
so nice when some of them already exist e.g. in a database
Le 05/06/2012 20:37, Alexandre Zani a écrit :
This is nice when your datetime objects are freshly created. It is not so
nice when some of them already exist e.g. in a database (using an ORM
layer). Mixing naive and aware datetimes is currently a catastrophe, since
even basic operations such as e
Le 08/06/2012 20:29, Brett Cannon a écrit :
> P.S. Do we need a python-implementations mailing list or
something for
> discussing overall VM-related stuff among all VMs instead of
always bringing
> this up on python-dev? E.g. I wish I had a place where I could
get all
On Mon, 11 Jun 2012 20:13:53 -0700
"fwierzbi...@gmail.com" wrote:
> On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlan wrote:
> > 1. Asking on python-dev is considered adequate. If an implementation
> > wants to be consulted on changes, one or more of their developers
> > *must* follow python-dev su
On Tue, 12 Jun 2012 11:23:28 +
Kristján Valur Jónsson wrote:
> Hi,
> Could I get some feedback on this proposed patch?
> It would be great to get it in before the beta.
The review I made on your previous patch still applies.
You shouldn't ask for feedback if you aren't willing to take it into
On Wed, 13 Jun 2012 13:47:28 +
Kristján Valur Jónsson wrote:
> I have reworked the patch, so it might be helpful to specify what exactly it
> is that you object to. Perhaps in the defect itself.
> I can add here that your worries that the previous patch defaulted to Vista
> specific feature
On Wed, 13 Jun 2012 11:20:24 -0700
Toshio Kuratomi wrote:
> On Wed, Jun 13, 2012 at 01:58:10PM -0400, R. David Murray wrote:
> >
> > OK, but you didn't answer the question :). If I understand correctly,
> > everything you said applies to *writing* the bytecode, not reading it.
> >
> > So, is th
On Wed, 13 Jun 2012 12:36:55 -0700
Ethan Furman wrote:
>
> Currently, the alternative to supporting this behavior is to either:
>
>1) require the end-user to specify -O (major nuisance)
>
>or
>
>2) have the distributor rename the .pyo file to .pyc
>
> I think 1 is a non-starter (n
On Thu, 14 Jun 2012 12:58:16 +0100
Floris Bruynooghe wrote:
> On 14 June 2012 11:25, Antoine Pitrou wrote:
> > Honestly, I think the best option would be to deprecate .pyo files as
> > well as the useless -O option. They only cause confusion without
> > providing any
On Thu, 14 Jun 2012 09:14:59 -0400
"R. David Murray" wrote:
>
> What does matter though is the memory savings. I'm working with an
> application where the difference between normal and -OO is around a 10%
> savings (about 2MB) in program DATA size at startup, and that makes a
> difference for an
On Thu, 14 Jun 2012 09:32:59 -0700
Benjamin Peterson wrote:
> >
> > How about adding 'kind' and keeping 'is_*' attributes,
> > but making them read-only dynamic properties, i.e.:
> >
> > class Parameter:
> > ...
> >
> > @property
> > def is_vararg(self):
> > return se
On Thu, 14 Jun 2012 12:46:38 -0700
Ethan Furman wrote:
>
> This is no different from what we have with strings now:
>
> --> 'aA'.islower()
> False
> --> 'aA'.isupper()
> False
> --> 'a'.islower()
> True
> --> 'A'.isupper()
> True
>
> We know that a string cannot be both all-upper and all-lower
On Fri, 15 Jun 2012 06:38:45 +1000
Steven D'Aprano wrote:
>
> Apart from the duplication of effort (everyone who wants to optimize their
> code has to write their own source-code strip tool),
Actually, it could be shipped with Python, or even done dynamically at
runtime (instead of relying on s
On Wed, 13 Jun 2012 22:52:43 -0400
Yury Selivanov wrote:
> * is_implemented : bool
> True if the parameter is implemented for use. Some platforms
> implement functions but can't support specific parameters
> (e.g. "mode" for ``os.mkdir``). Passing in an unimplemented
> parameter
On Thu, 14 Jun 2012 21:43:34 -0700
Larry Hastings wrote:
> On 06/14/2012 08:20 PM, Benjamin Peterson wrote:
> > 2012/6/14 Larry Hastings:
> >> Also, it's more granular than that. For example, Python now understands
> >> symbolic links on Windows--but only haphazardly at best. The
> >> "follow_s
On Fri, 15 Jun 2012 15:50:25 -0400
Yury Selivanov wrote:
>
> Open questions:
>
> 1. Should we keep 'Parameter.implemented' or not. *Please vote*
-1 to keeping it.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Fri, 15 Jun 2012 17:07:46 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> [snip]
> > Would it be possible to only create a signature for builtin the first
> > time that you read its __signature__ attribute? I don't know how to
> > implement such behaviour on a b
On Fri, 15 Jun 2012 17:26:25 -0400
Yury Selivanov wrote:
> On 2012-06-15, at 5:13 PM, Antoine Pitrou wrote:
>
> > On Fri, 15 Jun 2012 17:07:46 -0400
> > Yury Selivanov wrote:
> >> On 2012-06-15, at 4:48 PM, Victor Stinner wrote:
> >> [snip]
> >>>
On Sat, 16 Jun 2012 07:48:19 +1000
Steven D'Aprano wrote:
>
> The introduction of BindError will allow functions to raise a more specific,
> and less misleading, exception when they are called with the wrong number of
> arguments, or invalid keywords, etc.
If that's what you want, a separate P
On Sat, 16 Jun 2012 02:29:09 +0200
victor.stinner wrote:
> +if (from_kind == to_kind) {
> +if (!PyUnicode_IS_ASCII(from) && PyUnicode_IS_ASCII(to)) {
> +/* Writing Latin-1 characters into an ASCII string requires to
> + check that all written characters are pu
On Mon, 18 Jun 2012 15:28:24 +0100
Mark Shannon wrote:
>
> But do they? The results of benchmarking would seem to suggest (at least
> on my test machine) that overly-sparse dicts are slower.
> Possibly due to increased cache misses.
Or, at least, they are not faster. See the synthetic experiment
On Mon, 18 Jun 2012 21:31:27 +0200
Maciej Fijalkowski wrote:
> On Mon, Jun 18, 2012 at 5:04 PM, Antoine Pitrou wrote:
>
> > On Mon, 18 Jun 2012 15:28:24 +0100
> > Mark Shannon wrote:
> > >
> > > But do they? The results of benchmarking would seem to sugges
On Mon, 18 Jun 2012 13:46:25 -0700
Raymond Hettinger wrote:
>
> On Jun 18, 2012, at 12:35 PM, Antoine Pitrou wrote:
>
> > You are right. I was thinking 50 nanoseconds (which for a - relatively
> > high-end - 3GHz CPU puts us at 150 cycles).
>
> The last guidance I re
On Tue, 19 Jun 2012 01:41:44 +0200
brian.curtin wrote:
> http://hg.python.org/cpython/rev/8281233ec648
> changeset: 77514:8281233ec648
> user:Brian Curtin
> date:Mon Jun 18 18:41:07 2012 -0500
> summary:
> Fix #14772: Return the destination from some shutil functions.
>
> fi
Hi,
On Tue, 19 Jun 2012 04:39:30 -0700 (PDT)
gmspro wrote:
> Hi,
>
> I'm working on this bug to fix it. http://bugs.python.org/issue15068
I'm not sure why you think this is fixable, given the comments on the
tracker. What is your plan?
> >>> from sys import stdin
> >>> str=stdin.read()
> hell
On Tue, 19 Jun 2012 17:46:30 -0400
Éric Araujo wrote:
>
>I don’t think (a) would give us enough time; we really want a few
> months (and releases) to hash out the API (most notably with the pip and
> buildout developers) and clean the bdist situation. Likewise (c) would
> require develope
On Wed, 20 Jun 2012 15:00:52 +1000
Nick Coghlan wrote:
> On Wed, Jun 20, 2012 at 11:23 AM, Antoine Pitrou wrote:
> > The question is what will happen after 3.3. There doesn't seem to be a
> > lot of activity around the project, does it?
>
> I think the desire is th
On Wed, 20 Jun 2012 11:05:43 +0200
Dirkjan Ochtman wrote:
> On Wed, Jun 20, 2012 at 10:55 AM, Tarek Ziadé wrote:
> > So I prefer to hold it and have a solid implementation in the stldib. The
> > only thing I am asking is to retain ourselves to do *anything* in distutils
> > and continue to declar
On Tue, 19 Jun 2012 21:36:35 -0700
Guido van Rossum wrote:
> Nick nailed it (again).
Let's make things clear: packaging is suffering from a lack of
developer involvement, and a lack of user interest.
What makes you think that removing packaging from 3.3, and adding the
constraint of a new PEP to
On Wed, 20 Jun 2012 11:22:07 +0200
Tarek Ziadé wrote:
> I tried to improve Distutils and I was stopped and told to start
> distutils2, because
> distutils is so rotten, any *real* change/improvment potentially brakes
> the outside world.
If distutils was so rotten, distutils2 would not reuse mu
On Wed, 20 Jun 2012 09:51:03 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> >
> > Deciding to remove packaging from 3.3 is another instance of the same
> > mistake, IMO.
> >
>
> What's the rationale for leaving it in, w
On Wed, 20 Jun 2012 12:30:51 +0200
Tarek Ziadé wrote:
>
> >
> > Most of the distutils2 improvements (new PEPs, setup.cfg, etc.) were
> > totally possible in distutils, weren't they?
> I started there, remember ? And we ended up saying it was impossible to
> continue without
> breaking the packag
On Wed, 20 Jun 2012 13:20:04 +0200
Hynek Schlawack wrote:
>
> > and a lack of user interest.
>
> Maybe I'm getting you wrong here, but ISTM that proper packaging is in the
> short list on nearly everybody’s “things I wish they'd fix in Python”.
I agree, but I think people have also been burnt b
On Wed, 20 Jun 2012 12:11:03 +0100
Paul Moore wrote:
>
> I think the first question is, do we need an enhanced distutils in the
> stdlib?
I would answer a different question: we definitely need a better
distutils/packaging story. Whether it's in the form of distutils
enhancements, or another pac
On Thu, 21 Jun 2012 13:17:01 +0300
Daniel Braniss wrote:
> Hi,
> when lib/python/site-packages/ is accessed via NFS, open/stat/access is very
> expensive/slow.
>
> A simple solution is to use an in memory directory search/hash, so I was
> wondering if this has been concidered in the past, if not
On Thu, 21 Jun 2012 11:10:44 -
"Armin Ronacher" wrote:
> Hi,
>
> > Am 21.06.2012 12:23, schrieb Armin Ronacher:
> > Does the code handle a chain of absolute and relative symlinks
> > correctly, for example a relative symlink that points to another
> > relative symlink in a different directory
On Thu, 21 Jun 2012 15:04:17 +0200
Christian Heimes wrote:
>
> How about adding keyword support to OSError and derive the strerror from
> errno if the second argument is not given?
That's not the original behaviour:
Python 3.2.2+ (3.2:9ef20fbd340f, Oct 15 2011, 21:22:07)
[GCC 4.5.2] on linux2
On Thu, 21 Jun 2012 17:08:09 +0300
Daniel Braniss wrote:
> > There is such a thing in Python 3.3, although some stat() calls are
> > still necessary to know whether the directory caches are fresh.
> > Can you give it a try and provide some feedback?
>
> WOW!
> with a sample python program:
>
> i
On Thu, 21 Jun 2012 10:23:25 -
"Armin Ronacher" wrote:
> Due to an user error on my part I was not using os.readlink correctly.
> Since links can be relative to their location I think it would make sense
> to provide an os.path.resolve helper that automatically returns the
> absolute path:
>
On Thu, 21 Jun 2012 12:02:58 -0300
"Zooko Wilcox-O'Hearn" wrote:
>
> Fortunately, this issue is fixable! I opened a bug report and I and a
> others have provided patches that makes setuptools stop doing this
> behavior. This makes the above documentation true again. The negative
> impact on featu
On Thu, 21 Jun 2012 22:46:58 +0200
Dag Sverre Seljebotn wrote:
> > The other thing is, the folks in distutils2 and myself, have zero
> > knowledge about compilers. That's why we got very frustrated not to see
> > people with that knowledge come and help us in this area.
>
> Here's the flip side:
On Fri, 22 Jun 2012 15:05:08 +1000
Nick Coghlan wrote:
>
> So here's some sheer pie-in-the-sky speculation. If people like
> elements of this idea enough to run with it, great. If not... oh well:
Could this kind of discussion perhaps go on python-ideas?
Thanks
Antoine.
__
On Fri, 22 Jun 2012 12:27:19 +0100
Paul Moore wrote:
>
> Signed binaries may be a solution. My experience with signed binaries
> has not been exactly positive, but it's an option. Presumably PyPI
> would be the trusted authority? Would PyPI and the downloaders need to
> use SSL? Would developers
Hi,
As mentioned in the commit message for 96513d71e650, creating a type
using PyType_FromSpec seems to leak references when the type is
instantiated. This happens with SSLError:
>>> e = ssl.SSLError()
>>> sys.getrefcount(ssl.SSLError)
35
>>> e = ssl.SSLError()
>>> sys.getrefcount(ssl.SSLError
On Fri, 22 Jun 2012 21:23:10 +0200
Antoine Pitrou wrote:
>
> Hi,
>
> As mentioned in the commit message for 96513d71e650, creating a type
> using PyType_FromSpec seems to leak references when the type is
> instantiated. This happens with SSLError:
The patch in http://bugs.pyt
On Tue, 19 Jun 2012 17:46:30 -0400
Éric Araujo wrote:
>
>With beta coming, a way to deal with that unfortunate situation needs
> to be found. We could (a) grant an exception to packaging to allow
> changes after beta1; (b) keep packaging as it is now under a provisional
> status, with due
On Sat, 23 Jun 2012 11:00:34 +
Kristján Valur Jónsson wrote:
> I realize it is late, but any chance to get http://bugs.python.org/issue15139
> in today?
-1.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Sat, 23 Jun 2012 13:12:19 +0200
Antoine Pitrou wrote:
> On Sat, 23 Jun 2012 11:00:34 +
> Kristján Valur Jónsson wrote:
> > I realize it is late, but any chance to get
> > http://bugs.python.org/issue15139 in today?
>
> -1.
Let me elaborate: the patch hasn
On Sat, 23 Jun 2012 12:27:52 + (UTC)
Vinay Sajip wrote:
>
> For me, the bigger problem with the present distutils2/packaging
> implementation
> is that it propagates the command-class style of design which IMO caused so
> much pain in extending distutils. Perhaps some of the dafter limitatio
On Sat, 23 Jun 2012 12:32:37 +
Kristján Valur Jónsson wrote:
> Au contraire, it is actually a very major improvement, the result of pretty
> extensive profiling, see
> http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/
It might be. But to eval
On Sat, 23 Jun 2012 13:14:42 + (UTC)
Vinay Sajip wrote:
> Kudos to Tarek, Éric and others for taking this particular world on their
> shoulders and re-energizing the discussion and development work to date, but
> it
> seems the net needs to be spread even wider to ensure that all constituenci
On Sat, 23 Jun 2012 15:28:00 +0200
ezio.melotti wrote:
>
> + .. deprecated-removed:: 3.3 3.5
> + The *strict* argument and the strict mode have been deprecated.
> + The parser is now able to accept and parse invalid markup too.
> +
What if people want to accept only valid markup?
R
On Sat, 23 Jun 2012 14:14:46 + (UTC)
Vinay Sajip wrote:
>
> Some
> projects can be worked on in comparative isolation; other things, like
> packaging, need inputs from a wider range of people to gain the necessary
> credibility.
packaging already improves a lot over distutils. I don't see wh
Hello,
I've just noticed the following:
$ mkdir foo
$ ./python
Python 3.3.0a4+ (default:837d51ba1aa2+1794308c1ea7+, Jun 23 2012,
14:43:41) [GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo
>>> foo
Should even an empty directory be a val
On Sat, 23 Jun 2012 08:38:02 -0700
Guido van Rossum wrote:
> Yes. Otherwise, where to draw the line? What if it contains a single
> dot file? What if it contains no Python files? What if it contains
> only empty subdirectories?
That's true. I would have hoped for it to be recognized only when
the
On Sat, 23 Jun 2012 17:55:24 +0200
mar...@v.loewis.de wrote:
> > That's true. I would have hoped for it to be recognized only when
> > there's at least one module or package inside, but it doesn't sound
> > easy to check for (especially in the recursive namespace packages case
> > - is that possibl
On Sat, 23 Jun 2012 23:31:07 +0200
"Martin v. Löwis" wrote:
> I've been thinking about extensions to the stable ABI. On the one hand,
> introducing new API can cause extension modules not to run on older
> Python versions. On the other hand, the new API may well be stable in
> itself, i.e. remain
On Sun, 24 Jun 2012 11:05:35 -0400
"Eric V. Smith" wrote:
> On 06/23/2012 06:54 AM, g.brandl-nos...@gmx.net wrote:
> > I've decided to make Tuesday 26th the big release day. That means:
> >
> > - Saturday: last feature-level changes that should be done before beta,
> > e.g. removal of packaging
4501 - 4600 of 4909 matches
Mail list logo
