Am 04.02.2010 08:57, schrieb anatoly techtonik:
> Greetings,
>
> I'm writing a module for current Python 2.6 and I would like to
> reference documentation for Python 2.6, because I am not sure if
> behavior won't be changed in further series. So far I can link only
> to:
>
> http://docs.python.or
On approximately 2/4/2010 2:28 PM, came the following characters from
the keyboard of Eric Smith:
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters
from the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
varia
On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum wrote:
[..]
> I have one comment on PEP 345: Why is author-email mandatory? I'm sure
> there are plenty of cases where either the author doesn't want their
> email address published, or their last know email address is no longer
> valid. (Tarek resp
Glenn Linderman wrote:
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to th
On Thu, Feb 4, 2010 at 13:51, Nick Coghlan wrote:
> Brett Cannon wrote:
> > My thinking is we deprecate get_filename() and introduce some new method
> > that returns a two-item tuple (get_paths?). First item is where the
> > source should be, and the second is where the bytecode is if it exists
>
Glenn Linderman wrote:
> Alt. C... source-file-dir/__pyr_version__, each Python version with
> different bytecode would have some sort of version string or magic
> number that identifies it, and would look only in that directory for its
> .pyc/.pyo files. I prefer C for 4 reasons: 1) easier to blo
Brett Cannon wrote:
> My thinking is we deprecate get_filename() and introduce some new method
> that returns a two-item tuple (get_paths?). First item is where the
> source should be, and the second is where the bytecode is if it exists
> (else it's None). Putting both calculations into a single m
On Feb 4, 2010, at 4:59 AM, Barry Warsaw wrote:
> I still think this should go in 2.6.5. The patch does not apply to the
> current 2.6 branch because of changes in setup.py. If the patch is ported,
> reviewed and works with no regressions (when libreadline is both installed on
> OS X 10.5 and
On approximately 1/30/2010 4:00 PM, came the following characters from
the keyboard of Barry Warsaw:
When the Python executable is given a `-R` flag, or the environment
variable `$PYTHONPYR` is set, then Python will create a `foo.pyr`
directory and write a `pyc` file to that directory with the he
On Thu, Feb 4, 2010 at 00:57, anatoly techtonik wrote:
> Greetings,
>
> I'm writing a module for current Python 2.6 and I would like to
> reference documentation for Python 2.6, because I am not sure if
> behavior won't be changed in further series. So far I can link only
> to:
>
> http://docs.py
On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" wrote:
> 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 h
All,
I've reviewed PEP 345 and PEP 386 and am satisfied that after some
small improvements they will be accepted. Most of the discussion has
already taken place.
I have one comment on PEP 345: Why is author-email mandatory? I'm sure
there are plenty of cases where either the author doesn't want t
On 04:58 pm, jaeda...@gmail.com wrote:
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.
This require
Pascal Chambon writes:
> I don't really get it there... it seems to me that multiprocessing only
> requires picklability for the objects it needs to transfer, i.e those
> given as arguments to the called function, and thsoe put into
> multiprocessing queues/pipes. Global program data needn't be pic
On Feb 03, 2010, at 08:52 PM, Martin v. Löwis wrote:
>>> 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.
>>
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote:
>> Barry's answer was "yes" back in October.
>
>I will backport the patch if Barry says it's fine. Feel free to ping me if
>that doesn't happen before the end of next week.
I still think this should go in 2.6.5. The patch does not apply to th
Matt Knox a écrit :
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...
Brett Cannon wrote:
> But what does "expected location" mean? If I am importing foo.bar
> where foo.__path__ has multiple path entries, which one is supposed to
> be used to set the hypothetical location of source for __file__? I
> guess going with the first one would be somewhat reasonable, but it
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote:
>On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote:
>> -snip snip-
>> from __future__ import unicode_literals
>>
>> def func(foo, bar):
>> print foo, bar
>>
>> kw = {'foo': 7, 'bar': 9}
>> func(**kw)
>> -snip snip-
>>
>> T
Greetings,
I'm writing a module for current Python 2.6 and I would like to
reference documentation for Python 2.6, because I am not sure if
behavior won't be changed in further series. So far I can link only
to:
http://docs.python.org/ (stable, 2.6)
http://docs.python.org/dev/ (2.7)
http://docs.p
20 matches
Mail list logo
