On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote:
Barry Warsaw ba...@python.org writes:
I suppose this is going to be very subjective, but in skimming the
thread it seems like most people like putting the byte code cache
artifacts in subdirectories (be they siblings or
On approximately 2/2/2010 7:05 PM, came the following characters from
the keyboard of Guido van Rossum:
On Tue, Feb 2, 2010 at 5:41 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
On approximately 2/2/2010 4:28 PM, came the following characters from the
keyboard of Guido van Rossum:
On 03/02/2010 06:50, Barry Warsaw wrote:
I have to say up front that I'm somewhat shocked at how quickly this thread
has exploded! Since I'm sprinting this week, I haven't thoroughly read every
message and won't have time tonight to answer every question, but I'll try to
pick out some common
On 03/02/2010 06:50, Barry Warsaw wrote:
As to the question of sibling directories or folder-per-folder I think
performance issues should be the deciding factor. There are file system
limitations to consider (but also a wide variety of file systems in
use). Do
the number of stat calls
Reid Kleckner wrote:
On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter collinwin...@google.com wrote:
Wouldn't it be possible to have the compiler approach work
in three phases in order to reduce the memory footprint and
startup time hit, ie.
1. run an instrumented Python interpreter to collect
Barry Warsaw barry at python.org writes:
As to the question of sibling directories or folder-per-folder I think
performance issues should be the deciding factor. There are file system
limitations to consider (but also a wide variety of file systems in use). Do
the number of stat calls
Le Tue, 02 Feb 2010 22:57:11 -0800, Barry Warsaw a écrit :
On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
We deliberate don't document -U because its typical effect is break the
world - it makes all strings unicode in 2.x.
As an aside, I think this should be documented *somewhere* other
Ben Finney wrote:
I don't think keeping the cache files in a mass of intertwingled extra
subdirectories is the way to solve that problem. That speaks, rather, to
the need for Python to be able to find the file on behalf of the user
and blow it away on request, so the user doesn't need to go
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or
whatever compilation cache artifact file.
Well, I don't think we need another transition... Just
Barry Warsaw wrote:
On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
We deliberate don't document -U because its typical effect is break the
world - it makes all strings unicode in 2.x.
As an aside, I think this should be documented *somewhere* other than just in
import.c! I'd totally
Floris Bruynooghe wrote:
Personally I'm +1 on the folder-per-folder option.
Of all the proposed options, I also dislike the SVN/CVS style folder
structure the least ;)
Cheers,
Nick.
P.S. Translation of the double negative: I don't find any of the
solutions, even the current .pyc/.pyo approach,
Bob Ippolito wrote:
I like this option as well, but why not just name the directory .pyc
instead of __pyr__ or .pyr? That way people probably won't even have
to reconfigure their tools to ignore it :)
This actually came up in another part of the thread. The conclusion was
that, since the
Glenn Linderman wrote:
On approximately 2/2/2010 7:05 PM, came the following characters from
the keyboard of Guido van Rossum:
On Tue, Feb 2, 2010 at 5:41 PM, Glenn
Lindermanv+pyt...@g.nevcal.com wrote:
Agreed. But in reading that, it somehow triggered a question:
does zipimport only
Barry Warsaw wrote:
Encoding the magic number in the file name under .pyr would I thought make the
look up scheme more efficient since the import machinery can craft the file
name directly. I agree it's not very human friendly because nobody really
knows which magic numbers are associated
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith e...@trueblade.com wrote:
Mark Dickinson wrote:
What are the current plans for PEP 328 (the absolute imports PEP) in
Python 2.x?
Not sure about the decision one way or the other. But if there's not going
to be a 2.8, and if DeprecationWarnings are
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou solip...@pitrou.net wrote:
Since there might be several compiled files for a single source file (for
example, a .pyc along with a JITted native .so), __cache__ should probably be
a
tuple rather than a string.
But presumably there is only one
Mark Dickinson wrote:
Agreed on all points. Would it be terrible to simply add all relevant
tags the moment a PEP is accepted? E.g., if a PEP pronounces some
particular behaviour deprecated in Python 3.3 and removed in Python
3.4, then corresponding release blockers for 3.3 and 3.4 could be
On Feb 2, 2010, at 1:08 PM, Barry Warsaw wrote:
I'm thinking about doing a Python 2.6.5 release soon. I've added the
following dates to the Python release schedule Google calendar:
2009-03-01 Python 2.6.5 rc 1
2009-03-15 Python 2.6.5 final
This allows us to spend some time on 2.6.5 at
Mark Dickinson wrote:
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith e...@trueblade.com wrote:
Mark Dickinson wrote:
What are the current plans for PEP 328 (the absolute imports PEP) in
Python 2.x?
Not sure about the decision one way or the other. But if there's not going
to be a 2.8, and if
Nick Coghlan wrote:
Barry Warsaw wrote:
On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
We deliberate don't document -U because its typical effect is break the
world - it makes all strings unicode in 2.x.
It only affects string literals, not all strings.
As an aside, I think this should
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python 2.6 as well.
Jean-Paul
___
Python-Dev mailing list
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python 2.6 as well.
Right, but there are a few issues in 2.6 that will be
On 03:21 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python 2.6 as well.
Right, but there are
On Feb 03, 2010, at 11:31 PM, Nick Coghlan wrote:
Having a lookup dictionary from Python version + C API magic numbers to
the magic strings used in cache filenames in the import engine shouldn't
be too tricky. I'll admit it wasn't until the thread had already been
going for a while that I
On Feb 03, 2010, at 12:57 PM, Antoine Pitrou wrote:
How about doing measurements /with the current implementation/? Everyone
seems to worry about stat() calls but there doesn't seem to be any figures to
evaluate their significance.
Yes, very good idea, if for no other reason than to give us a
exar...@twistedmatrix.com wrote:
On 03:21 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python
Hi Barry,
Thanks for doing the work of writing a PEP. The rational section
could use some strengthing, I think. Who is benefiting from this
feature? Is it the distribution package maintainers? Maybe people
who use a distribution packaged Python and install packages from
PyPI. It's not clear
On Feb 03, 2010, at 11:10 PM, Nick Coghlan wrote:
Ripping it out is probably a reasonable idea given that there is a much
better approach available now (i.e. trying to run under Py3k) that
actually has a vague hope of working.
Then again, if 2.7 really is the last non-maintenance 2.x release,
Neil Schemenauer nas at arctrix.com writes:
Thanks for doing the work of writing a PEP. The rational section
could use some strengthing, I think. Who is benefiting from this
feature? Is it the distribution package maintainers? Maybe people
who use a distribution packaged Python and
On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote:
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module basis to achieve much the same effect.
In Python 2.6 as well.
On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw ba...@python.org wrote:
On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote:
exar...@twistedmatrix.com wrote:
On 02:52 pm, m...@egenix.com wrote:
Note that in Python 2.7 you can use
from __future__ import unicode_literals
on a per module
On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg m...@egenix.com wrote:
You lost me there :-)
I am not familiar with how U-S actually implements the compilation
step and was thinking of it working at the functions/methods level
and based on input/output parameter type information.
Yes, but it's
On Thu, Jan 14, 2010 at 6:56 AM, Jesse Noller jnol...@gmail.com wrote:
On Thu, Jan 14, 2010 at 9:08 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
From: Jesse Noller jnol...@gmail.com
I'm generally +1 - but given I know that Django 1.2 is slated to
implement something somewhat similar, I'm
On 2/3/2010 12:35 PM, Neil Schemenauer wrote:
Hi Barry,
Thanks for doing the work of writing a PEP. The rational section
could use some strengthing, I think. Who is benefiting from this
feature?
The original proposal of changing .pyc to a directory would be negative
to me so I would not
As an aside, I think this should be documented *somewhere* other than
just in import.c! I'd totally forgotten about it until I read the
source and almost missed it. Either it should be documented or it
should be ripped out.
The -U option is already gone in 3.x.
Precisely my view.
That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
feasible to back port that to Python 2.6? I remember talking about this a
while back but I don't remember what we decided and I can't find a bug on the
issue.
I don't know about feasible but I think it's
On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
In October 2009 I created PEP 391 to propose a new method of configuring
logging using dictionaries:
http://www.python.org/dev/peps/pep-0391/
In November 2009 I posted to this list that the PEP was ready for
This patch is still waiting a review and backporting from trunk.
http://mail.python.org/pipermail/python-dev/2009-October/092771.html
Can we get it in?
Only if one of the Mac people checks it in. As they are *REALLY* scarce,
the answer is probably no.
I'd offer a special version of the
- Original Message
From: Guido van Rossum gu...@python.org
To: Jesse Noller jnol...@gmail.com
Cc: Vinay Sajip vinay_sa...@yahoo.co.uk; python-dev@python.org
Assuming PEP 391 gets the nod, then after implementing the changes into
Python, I plan to work with the Django community to
On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
This patch is still waiting a review and backporting from trunk.
http://mail.python.org/pipermail/python-dev/2009-October/092771.html
Can we get it in?
Only if one of the Mac people checks it in.
It's already checked in the trunk by
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou solip...@pitrou.net wrote:
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or
whatever compilation cache
On Wed, Feb 3, 2010 at 05:57, Nick Coghlan ncogh...@gmail.com wrote:
Mark Dickinson wrote:
Agreed on all points. Would it be terrible to simply add all relevant
tags the moment a PEP is accepted? E.g., if a PEP pronounces some
particular behaviour deprecated in Python 3.3 and removed in
Barry Warsaw wrote:
On Feb 03, 2010, at 11:31 PM, Nick Coghlan wrote:
Having a lookup dictionary from Python version + C API magic numbers to
the magic strings used in cache filenames in the import engine shouldn't
be too tricky. I'll admit it wasn't until the thread had already been
going
On Wed, Feb 3, 2010 at 05:27, Nick Coghlan ncogh...@gmail.com wrote:
Glenn Linderman wrote:
On approximately 2/2/2010 7:05 PM, came the following characters from
the keyboard of Guido van Rossum:
On Tue, Feb 2, 2010 at 5:41 PM, Glenn
Lindermanv+pyt...@g.nevcal.com wrote:
Agreed. But in
Nick Coghlan ncogh...@gmail.com writes:
P.S. Translation of the double negative: I don't find any of the
solutions, even the current .pyc/.pyo approach, to be particularly
elegant, so I can't really say I like any of them in an absolute
sense. However, having a single cache folder inside each
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan ncogh...@gmail.com wrote:
On the issue of __file__, I'd suggesting not being too hasty in
deprecating that in favour of __source__. While I can see a lot of value
in having it point to the source file more often with a different
attribute that
On Wed, Feb 3, 2010 at 12:00 PM, Martin v. Löwis mar...@v.loewis.de wrote:
That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
feasible to back port that to Python 2.6? I remember talking about this a
while back but I don't remember what we decided and I can't find a
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou solip...@pitrou.net wrote:
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for that, with __cache__ for the location of the PVM, JVM, LLVM
or
whatever compilation
Guido van Rossum wrote:
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan ncogh...@gmail.com wrote:
On the issue of __file__, I'd suggesting not being too hasty in
deprecating that in favour of __source__. While I can see a lot of value
in having it point to the source file more often with a
Guido van Rossum wrote:
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan ncogh...@gmail.com wrote:
On the issue of __file__, I'd suggesting not being too hasty in
deprecating that in favour of __source__. While I can see a lot of value
in having it point to the source file more often with a
On Wed, Feb 3, 2010 at 13:30, Martin v. Löwis mar...@v.loewis.de wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou solip...@pitrou.net wrote:
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for that, with
Ben Finney wrote:
Nick Coghlan ncogh...@gmail.com writes:
P.S. Translation of the double negative: I don't find any of the
solutions, even the current .pyc/.pyo approach, to be particularly
elegant, so I can't really say I like any of them in an absolute
sense. However, having a single
Brett Cannon wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou solip...@pitrou.net wrote:
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for that, with __cache__ for the location of the PVM, JVM, LLVM
or
Le Wed, 03 Feb 2010 15:55:54 +0200, Simon Cross a écrit :
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou solip...@pitrou.net
wrote:
Since there might be several compiled files for a single source file
(for example, a .pyc along with a JITted native .so), __cache__ should
probably be a tuple
On Wed, Feb 3, 2010 at 13:52, Nick Coghlan ncogh...@gmail.com wrote:
Brett Cannon wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou solip...@pitrou.net wrote:
Barry Warsaw barry at python.org writes:
Python 3 uses the .py file for __file__ but I'd like to see a transition to
__source__ for
On 03/02/2010 22:05, Brett Cannon wrote:
On Wed, Feb 3, 2010 at 13:52, Nick Coghlanncogh...@gmail.com wrote:
Brett Cannon wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrousolip...@pitrou.net wrote:
Barry Warsawbarryat python.org writes:
Python 3 uses the .py
On Wed, Feb 3, 2010 at 14:40, Michael Foord fuzzy...@voidspace.org.uk
wrote:
On 03/02/2010 22:05, Brett Cannon wrote:
On Wed, Feb 3, 2010 at 13:52, Nick Coghlanncogh...@gmail.com wrote:
Brett Cannon wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrousolip...@pitrou.net
wrote:
Barry
At 10:40 PM 2/3/2010 +, Michael Foord wrote:
Isn't __file__ usually baked into .pyc files at compile time? (At
least I assumed that from the incorrect tracebacks on Windows when
you ship just .pyc files.)
That's code.co_filename, which is not necessarily the same as __file__.
On Wed, Feb 3, 2010 at 14:40, Michael Foord fuzzy...@voidspace.org.uk
wrote:
Isn't __file__ usually baked into .pyc files at compile time? (At least I
assumed that from the incorrect tracebacks on Windows when you ship just
.pyc files.)
On Wed, Feb 3, 2010 at 2:48 PM, Brett Cannon
On 3 Feb, 2010, at 21:27, Zvezdan Petkovic wrote:
On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
This patch is still waiting a review and backporting from trunk.
http://mail.python.org/pipermail/python-dev/2009-October/092771.html
Can we get it in?
Only if one of the Mac people
Thanks for the explanation.
Nick Coghlan ncogh...@gmail.com writes:
Being able to get rid of the existing .pyc/.pyo clutter at the same
time is just a bonus.
Okay. I maintain (unsurprisingly) that replacing it with subdirectory
clutter is a poor bargain. But I have nothing new to add on that
Jesse Noller jnoller at gmail.com writes:
We already have an implementation that spawns a
subprocess and then pushes the required state to the child. The
fundamental need for things to be pickleable *all the time* kinda
makes it annoying to work with.
just a lurker here... but this topic
62 matches
Mail list logo
