Jesse Noller 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 hits h
Thanks for the explanation.
Nick Coghlan 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 score
for now.
-
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 on
> On Wed, Feb 3, 2010 at 14:40, 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.)
On Wed, Feb 3, 2010 at 2:48 PM, Brett Cannon wrote:
> Yes, but import.c
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
wrote:
> On 03/02/2010 22:05, Brett Cannon wrote:
>>
>> On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote:
>>
>>>
>>> Brett Cannon wrote:
>>>
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou
wrote:
>
> Barry Warsaw python.org>
On 03/02/2010 22:05, Brett Cannon wrote:
On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote:
Brett Cannon wrote:
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Python 3 uses the .py file for __file__ but I'd like to see a tra
On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote:
> Brett Cannon wrote:
>> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
>>> Barry Warsaw 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 lo
Le Wed, 03 Feb 2010 15:55:54 +0200, Simon Cross a écrit :
> On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou
> 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
Brett Cannon wrote:
> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
>> Barry Warsaw 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 compila
Ben Finney wrote:
> Nick Coghlan 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
On Wed, Feb 3, 2010 at 13:30, "Martin v. Löwis" wrote:
>> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
>>> Barry Warsaw 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
Guido van Rossum wrote:
> On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan 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
>> attr
Guido van Rossum wrote:
> On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan 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
>> attr
> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
>> Barry Warsaw 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
On Wed, Feb 3, 2010 at 12:00 PM, "Martin v. Löwis" 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 bug on
>>
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan 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 points to the cache
Nick Coghlan 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 Python source
On Wed, Feb 3, 2010 at 05:27, Nick Coghlan 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
>>> Linderman wrote:
Agreed. But in reading that, it somehow tr
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
On Wed, Feb 3, 2010 at 05:57, Nick Coghlan 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 Python
>> 3.4, t
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote:
> Barry Warsaw 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.
>
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
- Original Message
> From: Guido van Rossum
> To: Jesse Noller
> Cc: Vinay Sajip ; 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 get improved logging
> support
> in Django for 1
> 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
On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip 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 review.
>
> I have had n
>> 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 (
>> 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
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 use
On Thu, Jan 14, 2010 at 6:56 AM, Jesse Noller wrote:
> On Thu, Jan 14, 2010 at 9:08 AM, Vinay Sajip wrote:
>>> From: Jesse Noller
>>
>>> I'm generally +1 - but given I know that Django 1.2 is slated to
>>> implement something somewhat similar, I'm interested to hear how this
>>> proposal meshes
On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg 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 more like
On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw 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
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 P
Neil Schemenauer 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 instal
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
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 t
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
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
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 real
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
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 t
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
Python-Dev@
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 thin
Mark Dickinson wrote:
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith 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 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.
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
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou 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 compiled file that
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith 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 off by defa
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
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
>> Linderman wrote:
>>> Agreed. But in reading that, it somehow triggered a question:
>>> does zipimport only work for zipf
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 cac
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,
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
Barry Warsaw 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 keep
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
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
Barry Warsaw 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 predomi
Reid Kleckner wrote:
> On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter 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 all
>>>
> 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
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 ide
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 Linderman wrote:
On approximately 2/2/2010 4:28 PM, came the following characters from the
keyboard of Guido van Rossum:
Argh. zipfiles are wa
On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote:
> Barry Warsaw 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 folder-per-folder)
62 matches
Mail list logo
