On Thu, Jun 24, 2010 at 09:05:09PM -0400, Alexander Belopolsky wrote:
> On Thu, Jun 24, 2010 at 8:51 PM, Rich Healey wrote:
> > http://docs.python.org/library/copy.html
> >
> > Just near the bottom it reads:
> >
> > """Shallow copies of dictionaries can be made using dict.copy(), and
> > of lists
On Fri, Jun 25, 2010 at 11:18 AM, Terry Reedy wrote:
> I believe there is material on the wiki as well as the two existing pages on
> other sites that were discussed here. So a new page on python.org could
> consist of a few links. Someone just has to write it.
There's material on the wiki *now*
Terry Reedy wrote:
On 6/24/2010 1:38 PM, Bill Janssen wrote:
We have separate types for int,
float, Decimal, etc. But they're all numbers, and they all
cross-operate.
No they do not. Decimal only mixes properly with ints, but not with
anything else
I think there are also some important di
On 6/24/2010 8:31 PM, Stephen Thorne wrote:
Oh, I thought this was quite clear. I was specifically meaning the large
"Python 2 or 3" button on python.org. It would help users who want to know
what version of python to use if they had a clear guide as to what version
to download.
I think everyo
On Fri, Jun 25, 2010 at 11:04 AM, Steve Holden wrote:
> Rich Healey wrote:
>> http://docs.python.org/library/copy.html
>>
>> Just near the bottom it reads:
>>
>> """Shallow copies of dictionaries can be made using dict.copy(), and
>> of lists by assigning a slice of the entire list, for example,
>
Scott Dial wrote:
But the only motivation for doing this with .pyc files is that the .py
files are able to be shared,
In an application made up of a mixture of pure Python and
extension modules, the .py files are able to be shared too.
Seems to me that a similar motivation exists here as well.
On Thu, Jun 24, 2010 at 8:51 PM, Rich Healey wrote:
> http://docs.python.org/library/copy.html
>
> Just near the bottom it reads:
>
> """Shallow copies of dictionaries can be made using dict.copy(), and
> of lists by assigning a slice of the entire list, for example,
> copied_list = original_list[
Rich Healey wrote:
> http://docs.python.org/library/copy.html
>
> Just near the bottom it reads:
>
> """Shallow copies of dictionaries can be made using dict.copy(), and
> of lists by assigning a slice of the entire list, for example,
> copied_list = original_list[:]."""
>
>
> Surely this is a
Stephen Thorne wrote:
> On 2010-06-25, "Martin v. Löwis" wrote:
>> Am 25.06.2010 01:28, schrieb Stephen Thorne:
>>> Steve Holden Wrote:
Given the amount of interest this thread has generated I can't help
wondering why it isn't more prominent in python.org content. Is the
developer co
James Y Knight writes:
> Really, python should store the .py files in /usr/share/python/, the
> .so files in /usr/lib/x86_64- linux-gnu/python2.5-debug/, and the .pyc
> files in /var/lib/python2.5- debug. But python doesn't work like that.
+1
So who's going to draft the “Filesystem Hierarchy St
http://docs.python.org/library/copy.html
Just near the bottom it reads:
"""Shallow copies of dictionaries can be made using dict.copy(), and
of lists by assigning a slice of the entire list, for example,
copied_list = original_list[:]."""
Surely this is a typo? To my understanding, copied_list
On 2010-06-25, "Martin v. Löwis" wrote:
> Am 25.06.2010 01:28, schrieb Stephen Thorne:
> > Steve Holden Wrote:
> >> Given the amount of interest this thread has generated I can't help
> >> wondering why it isn't more prominent in python.org content. Is the
> >> developer community completely disjoi
On Jun 24, 2010, at 5:53 PM, Scott Dial wrote:
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
Specifically, it's the use case where we (Debian/Ubuntu) plan on
installing
all Python 3.x packages into /usr/lib/python3/dist-packages. As of
PEP 3147,
we can do th
Am 25.06.2010 01:28, schrieb Stephen Thorne:
> Steve Holden Wrote:
>> Given the amount of interest this thread has generated I can't help
>> wondering why it isn't more prominent in python.org content. Is the
>> developer community completely disjoint with the web content editor
>> community?
>>
>>
Steve Holden Wrote:
> Given the amount of interest this thread has generated I can't help
> wondering why it isn't more prominent in python.org content. Is the
> developer community completely disjoint with the web content editor
> community?
>
> If there is such a disconnect we should think about
On Fri, Jun 25, 2010 at 1:50 AM, Barry Warsaw wrote:
> Please let me know what you think. I'm happy to just commit this to the py3k
> branch if there are no objections . I don't think a new PEP is in
> order, but an update to PEP 3147 might make sense.
I like the idea, but I think summarising t
Scott Dial wrote:
> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
>>> What use case does this address?
>>
>>> If you want to make it so a system can install a package in just one
>>> location to be used by multiple Python installations, then the version
>>> number isn't enough. You also need to distin
On 6/24/2010 4:59 PM, Guido van Rossum wrote:
But I wouldn't go so far as to claim that interpreting the protocols
as text is wrong. After all we're talking exclusively about protocols
that are designed intentionally to be directly "human readable"
I agree that the claim "':' is just a byte" i
On Fri, Jun 25, 2010 at 1:41 AM, Guido van Rossum wrote:
> I don't think we should abuse sum for this. A simple idiom to get the
> *empty* string of a particular type is x[:0] so you could write
> something like this to concatenate a list or strings or bytes:
> xs[:0].join(xs). Note that if xs is
On Thu, Jun 24, 2010 at 2:44 PM, Ian Bicking wrote:
> I think we'll avoid a lot of the confusion that was present with Python 2 by
> not making the coercions transitive. For instance, here's something that
> would work in Python 2:
>
> urlunsplit(('http', 'example.com', '/foo', u'bar=baz', ''))
On Fri, Jun 25, 2010 at 3:07 AM, P.J. Eby wrote:
> (Btw, in some earlier emails, Stephen, you implied that this could be fixed
> with codecs -- but it can't, because the problem isn't with the bytes
> containing invalid Unicode, it's with the Unicode containing invalid bytes
> -- i.e., characters
On 6/24/2010 1:38 PM, Bill Janssen wrote:
Secondly, maybe the string situation in 2.x wasn't as broken as we
thought it was. In particular, those who deal with lots of encoded
strings seemed to find it handy, and miss it in 3.x. Perhaps strings
are more like numbers than we think. We have sep
On 6/24/2010 5:09 PM, Barry Warsaw wrote:
>> What use case does this address?
>
> Specifically, it's the use case where we (Debian/Ubuntu) plan on installing
> all Python 3.x packages into /usr/lib/python3/dist-packages. As of PEP 3147,
> we can do that without collisions on the pyc files, but wo
On Thu, 24 Jun 2010 20:07:41 +0100
Michael Foord wrote:
>
> Although it would require changes for builtin types like file to work
> with a new string ABC, right?
There is no builtin file type in 3.x.
Besides, it is not an ABC-level problem; the IO layer is written in C
(although there's still t
On Thu, Jun 24, 2010 at 3:59 PM, Guido van Rossum wrote:
> The protocol specs typically go out of their way to specify what byte
> values they use for syntactically significant positions (e.g. ':' in
> headers, or '/' in URLs), while hand-waving about the meaning of "what
> goes in between" since
Your plan seems good. Adding keyword arguments should not create
compatibility issues, and I suspect the impact on the code of build_ext
may be actually quite small. I’ll try to review your patch even though I
don’t know C or compiler oddities, but Tarek will have the best insight
and the final wor
On Jun 24, 2010, at 11:50 AM, Barry Warsaw wrote:
>Please let me know what you think. I'm happy to just commit this to the py3k
>branch if there are no objections . I don't think a new PEP is in
>order, but an update to PEP 3147 might make sense.
Thanks for all the quick feedback. I've made so
On Jun 24, 2010, at 08:50 PM, Éric Araujo wrote:
>Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
>> Other possible approaches:
>> * Extend the distutils API so that the .so file extension can be passed in,
>>instead of being essentially hardcoded to what Python's Makefile contains.
>
>Th
On Thu, Jun 24, 2010 at 4:55 PM, Barry Warsaw wrote:
> Which is probably another reason not to use foo.so.X.Y for Python extension
> modules.
Clearly, foo.so.3.2 is the man page for the foo.so.3 system call.
The ABI ident definitely has to be elsewhere.
-Fred
--
Fred L. Drake, Jr.
"A s
On Jun 24, 2010, at 11:05 AM, Daniel Stutzbach wrote:
>On Thu, Jun 24, 2010 at 10:50 AM, Barry Warsaw wrote:
>
>> The idea is to put the Python version number in the shared library file
>> name,
>> and extend .so lookup to find these extended file names. So for example,
>> we'd
>> see foo.3.2.so
On Thu, Jun 24, 2010 at 11:53, Éric Araujo wrote:
> Le 24/06/2010 19:48, Brett Cannon a écrit :
>> P.S.: I wish we could drop use of the 'module.so' variant at the same
>> time, for consistency sake and to cut out a stat call, but I know that
>> is asking too much.
>
> At least, looking for spam/_
I see it a little differently (though there is probably a common
concept lurking in here).
The protocols you mention are intentionally designed to be
encoding-neutral as long as the encoding is an ASCII superset. This
covers ASCII itself, Latin-1, Latin-N for other values of N, MacRoman,
Microsoft
On Jun 24, 2010, at 11:27 AM, Guido van Rossum wrote:
>On Thu, Jun 24, 2010 at 10:48 AM, Brett Cannon wrote:
>> While the idea is fine with me since I won't have any of my
>> directories cluttered with multiple .so files, I would still want to
>> add some moniker showing that the version number r
On Jun 24, 2010, at 10:48 AM, Brett Cannon wrote:
>While the idea is fine with me since I won't have any of my
>directories cluttered with multiple .so files, I would still want to
>add some moniker showing that the version number represents the
>interpreter and not the .so file. If I read "foo.3.
On Jun 24, 2010, at 02:28 PM, Barry Warsaw wrote:
>On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
>
>>2010/6/24 Barry Warsaw :
>>> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>>>
2010/6/24 Barry Warsaw :
> Please let me know what you think. I'm happy to just commit this
On Thu, Jun 24, 2010 at 12:38 PM, Bill Janssen wrote:
> Here are a couple of ideas I'm taking away from the bytes/string
> discussion.
>
> First, it would probably be a good idea to have a String ABC.
>
> Secondly, maybe the string situation in 2.x wasn't as broken as we
> thought it was. In par
On Thu, Jun 24, 2010 at 12:07, Michael Foord wrote:
> On 24/06/2010 19:11, Brett Cannon wrote:
>>
>> On Thu, Jun 24, 2010 at 10:38, Bill Janssen wrote:
>> [SNIP]
>>
>>>
>>> The language moratorium kind of makes this all theoretical, but building
>>> a String ABC still would be a good start, and p
On 24/06/2010 19:11, Brett Cannon wrote:
On Thu, Jun 24, 2010 at 10:38, Bill Janssen wrote:
[SNIP]
The language moratorium kind of makes this all theoretical, but building
a String ABC still would be a good start, and presumably isn't forbidden
by the moratorium.
Because a new ABC wo
Le 24/06/2010 19:48, Brett Cannon a écrit :
> P.S.: I wish we could drop use of the 'module.so' variant at the same
> time, for consistency sake and to cut out a stat call, but I know that
> is asking too much.
At least, looking for spam/__init__module.so could be avoided. It seems
to me that the
Le 24/06/2010 17:50, Barry Warsaw (FLUFL) a écrit :
> Other possible approaches:
> * Extend the distutils API so that the .so file extension can be passed in,
>instead of being essentially hardcoded to what Python's Makefile contains.
Third-party code rely on Distutils internal quirks, so it’
On Thu, Jun 24, 2010 at 11:27, Guido van Rossum wrote:
> On Thu, Jun 24, 2010 at 10:48 AM, Brett Cannon wrote:
>> On Thu, Jun 24, 2010 at 08:50, Barry Warsaw wrote:
>>> This is a follow up to PEP 3147. That PEP, already implemented in Python
>>> 3.2,
>>> allows for Python source files from dif
On Jun 24, 2010, at 01:00 PM, Benjamin Peterson wrote:
>2010/6/24 Barry Warsaw :
>> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>>
>>>2010/6/24 Barry Warsaw :
Please let me know what you think. I'm happy to just commit this to the
py3k branch if there are no objections . I d
On Thu, Jun 24, 2010 at 10:48 AM, Brett Cannon wrote:
> On Thu, Jun 24, 2010 at 08:50, Barry Warsaw wrote:
>> This is a follow up to PEP 3147. That PEP, already implemented in Python
>> 3.2,
>> allows for Python source files from different Python versions to live
>> together
>> in the same dir
On Thu, Jun 24, 2010 at 10:38, Bill Janssen wrote:
[SNIP]
> The language moratorium kind of makes this all theoretical, but building
> a String ABC still would be a good start, and presumably isn't forbidden
> by the moratorium.
Because a new ABC would go into the stdlib (I assume in collections
2010/6/24 Barry Warsaw :
> On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>
>>2010/6/24 Barry Warsaw :
>>> Please let me know what you think. I'm happy to just commit this to the
>>> py3k branch if there are no objections . I don't think a new PEP is
>>> in order, but an update to PEP 314
On Jun 24, 2010, at 10:58 AM, Benjamin Peterson wrote:
>2010/6/24 Barry Warsaw :
>> Please let me know what you think. I'm happy to just commit this to the
>> py3k branch if there are no objections . I don't think a new PEP is
>> in order, but an update to PEP 3147 might make sense.
>
>How will
On Thu, Jun 24, 2010 at 08:50, Barry Warsaw wrote:
> This is a follow up to PEP 3147. That PEP, already implemented in Python 3.2,
> allows for Python source files from different Python versions to live together
> in the same directory. It does this by putting a magic tag in the .pyc file
> name
Here are a couple of ideas I'm taking away from the bytes/string
discussion.
First, it would probably be a good idea to have a String ABC.
Secondly, maybe the string situation in 2.x wasn't as broken as we
thought it was. In particular, those who deal with lots of encoded
strings seemed to find
At 05:12 PM 6/24/2010 +0900, Stephen J. Turnbull wrote:
Guido van Rossum writes:
> For example: how we can make the suite of functions used for URL
> processing more polymorphic, so that each developer can choose for
> herself how URLs need to be treated in her application.
While you have co
P.J. Eby a écrit :
[...] stdlib constants are almost always ASCII,
and the main use cases for ebytes would involve ascii-extended encodings.)
Then, how about a new "ascii string" literal? This would produce a special kind
of string that would coerce to a normal string when mixed with a str, a
On Thu, Jun 24, 2010 at 10:50 AM, Barry Warsaw wrote:
> The idea is to put the Python version number in the shared library file
> name,
> and extend .so lookup to find these extended file names. So for example,
> we'd
> see foo.3.2.so instead, and Python would know how to dynload both that and
>
2010/6/24 Barry Warsaw :
> Please let me know what you think. I'm happy to just commit this to the py3k
> branch if there are no objections . I don't think a new PEP is in
> order, but an update to PEP 3147 might make sense.
How will this interact with PEP 384 if that is implemented?
--
Rega
This is a follow up to PEP 3147. That PEP, already implemented in Python 3.2,
allows for Python source files from different Python versions to live together
in the same directory. It does this by putting a magic tag in the .pyc file
name and placing the .pyc file in a __pycache__ directory.
Dist
On Thu, Jun 24, 2010 at 8:25 AM, Nick Coghlan wrote:
> On Fri, Jun 25, 2010 at 12:33 AM, Guido van Rossum wrote:
>> Also, IMO a polymorphic function should *not* accept *mixed*
>> bytes/text input -- join('x', b'y') should be rejected. But join('x',
>> 'y') -> 'x/y' and join(b'x', b'y') -> b'x/y'
On Fri, Jun 25, 2010 at 12:33 AM, Guido van Rossum wrote:
> Also, IMO a polymorphic function should *not* accept *mixed*
> bytes/text input -- join('x', b'y') should be rejected. But join('x',
> 'y') -> 'x/y' and join(b'x', b'y') -> b'x/y' make sense to me.
A policy of allowing arguments to be ei
On Thu, Jun 24, 2010 at 1:12 AM, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
>
> > For example: how we can make the suite of functions used for URL
> > processing more polymorphic, so that each developer can choose for
> > herself how URLs need to be treated in her application.
>
> Wh
On 24/06/2010 11:58, M.-A. Lemburg wrote:
Lennart Regebro wrote:
On Tue, Jun 22, 2010 at 20:07, James Y Knight wrote:
Yeah. This is a real issue I have with the direction Python3 went: it pushes
you into decoding everything to unicode early, even when you don't care --
Well,
Lennart Regebro wrote:
> On Tue, Jun 22, 2010 at 20:07, James Y Knight wrote:
>> Yeah. This is a real issue I have with the direction Python3 went: it pushes
>> you into decoding everything to unicode early, even when you don't care --
>
> Well, yes, maybe even if *you* don't care. But often the
On Tue, Jun 22, 2010 at 20:07, James Y Knight wrote:
> Yeah. This is a real issue I have with the direction Python3 went: it pushes
> you into decoding everything to unicode early, even when you don't care --
Well, yes, maybe even if *you* don't care. But often the functions you
need to call must
Guido van Rossum writes:
> For example: how we can make the suite of functions used for URL
> processing more polymorphic, so that each developer can choose for
> herself how URLs need to be treated in her application.
While you have come down on the side of polymorphism (as opposed to
separat
Ronald Oussoren wrote:
That's because setgroups(3) is limited to 16 groups
> (that is, the kernel doesn't support more than 16 groups at all).
So how does an account being a member of 18 groups ever work?
--
Greg
___
Python-Dev mailing list
Python-D
61 matches
Mail list logo
