Re: [Python-Dev] r88516 - in python/branches/py3k/Python: dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c dynload_shlib.c dynload_win.c importdl.c

This commit introduced tabs, at least in dynload_dl.c. Georg On 23.02.2011 00:16, victor.stinner wrote: > Author: victor.stinner > Date: Wed Feb 23 00:16:19 2011 > New Revision: 88516 > > Log: > Issue #3080: Remove unused argument of _PyImport_GetDynLoadFunc() > > The first argument, fqname, wa

Re: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py

You're sure this will not cause tedious conflicts with backports? Georg On 22.02.2011 16:56, giampaolo.rodola wrote: > Author: giampaolo.rodola > Date: Tue Feb 22 16:56:20 2011 > New Revision: 88501 > > Log: > smtlib.py PEP8 normalization via pep8.py script. > > Modified: >python/branches/p

Re: [Python-Dev] svn outage on Friday

Am 23.02.2011 02:43, schrieb Nick Coghlan: > On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer than an

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

Jesus Cea writes: > Every time I read a message from [long, incomplete list] and > so many others python-devs (not an exhaustive list, if you are not > there, you probably should, sorry :), I feel I am faking my > knowledge of Python :-). I am a pretender :). Sure. I suspect even some of tho

Re: [Python-Dev] [Python-checkins] r88505 - python/branches/py3k/Lib/ftplib.py

I'll do. 2011/2/23 Victor Stinner : > You should maybe backport this fix to Python 3.2. > > Le mardi 22 février 2011 à 20:24 +0100, giampaolo.rodola a écrit : >> Author: giampaolo.rodola >> Date: Tue Feb 22 20:24:33 2011 >> New Revision: 88505 >> >> Log: >> In FTP.close() method, make sure to also

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/02/11 03:31, Stephen J. Turnbull wrote: > Please don't wait for consensus or even a second opinion to file the > issue. > > It's reasonable for a new Python user to ask whether something is a > bug or not, but if somebody with your experience an

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

On Tue, Feb 22, 2011 at 9:31 PM, Stephen J. Turnbull wrote: > Jesus Cea writes: > >  > PPS: If there is consensus that this is a real bug, I would create an >  > issue in the tracker and try to get a minimal testcase. > > All bugs are issues, but not all issues are bugs. > > Please don't wait for

[Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

Jesus Cea writes: > PPS: If there is consensus that this is a real bug, I would create an > issue in the tracker and try to get a minimal testcase. All bugs are issues, but not all issues are bugs. Please don't wait for consensus or even a second opinion to file the issue. It's reasonable for

Re: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3

2011/2/22 brett.cannon : > Author: brett.cannon > Date: Tue Feb 22 20:12:43 2011 > New Revision: 88503 > > Log: > Add lib2to3.__main__ to make it easier for debugging purposes to run 2to3. Please revert this and do it in the sandbox. > > Added: >   python/branches/py3k/Lib/lib2to3/__main__.py > M

Re: [Python-Dev] svn outage on Friday

On Feb 22, 2011, at 5:43 PM, Nick Coghlan wrote: > On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer

Re: [Python-Dev] svn outage on Friday

On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote: > I'm going to perform a Debian upgrade of svn.python.org on Friday, > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > that time. The outage shouldn't be longer than an hour. This may have caused some issues with th

Re: [Python-Dev] [Python-checkins] r88505 - python/branches/py3k/Lib/ftplib.py

You should maybe backport this fix to Python 3.2. Le mardi 22 février 2011 à 20:24 +0100, giampaolo.rodola a écrit : > Author: giampaolo.rodola > Date: Tue Feb 22 20:24:33 2011 > New Revision: 88505 > > Log: > In FTP.close() method, make sure to also close the socket object, not only > the file.

Re: [Python-Dev] Fwd: deep question re dict as formatting input

On 2/22/2011 6:28 PM, Steve Holden wrote: On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: Quoting PEP 3101: An example of the 'getitem' syntax: "My name is {0[name]}".format(dict(name='Fred')) It should be noted that the use of 'getitem' within a format string is much more limited th

Re: [Python-Dev] Fwd: deep question re dict as formatting input

On 2/22/2011 6:32 PM, Senthil Kumaran wrote: On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: ... It would appear from tests that "{0[X]}".format(...) first tries to convert the string "X" to in integer. If it succeeds then __getitem__() is called with the integer as an argument, otherwise

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> I don't think it's a good idea to backport visible API changes. > (someone successfully compiling on 2.7.N could then have users > complaining that compilation fails on 2.7.N-1). +1. If it was a bug fix (which it isn't), having this kind of breakage would be fine, of course (i.e. code relying on

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, Feb 22, 2011 at 6:36 PM, Antoine Pitrou wrote: .. > To quote the message above: someone successfully compiling on 2.7.N > could then have users complaining that compilation fails on 2.7.N-1. > (note: *N-1*) I missed that. Yes, this is a valid concern. I change my vote from -0 to -1. :-)

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> Even if it is eventually decided not to backport those patches to 2.7, > it would be nice if the documentation could be updated to indicate > that strings passed to those functions won't be modified, so that API > users like myself can feel a little safer when passing literals in, > without havin

Re: [Python-Dev] Const-correctness in C-API Object Protocol

Le mardi 22 février 2011 à 18:30 -0500, Alexander Belopolsky a écrit : > On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou wrote: > .. > > I don't think it's a good idea to backport visible API changes. > > (someone successfully compiling on 2.7.N could then have users > > complaining that compilati

Re: [Python-Dev] %-formatting depracation

On Tue, 2011-02-22 at 23:03 +0100, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 07:52:23 +1000 > Nick Coghlan wrote: > > > On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > > > The very long term view is for %-formatting to go away, but that's as far > > > as > > > the thinking has gone. Th

Re: [Python-Dev] Fwd: deep question re dict as formatting input

> On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: >> ... It would appear from tests >> that "{0[X]}".format(...) first tries to convert the string "X" to in >> integer. If it succeeds then __getitem__() is called with the integer as an >> argument, otherwise it is called with the string itsel

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou wrote: .. > I don't think it's a good idea to backport visible API changes. > (someone successfully compiling on 2.7.N could then have users > complaining that compilation fails on 2.7.N-1). > Moreover, it doesn't really fix a bug. That was the argu

Re: [Python-Dev] Fwd: deep question re dict as formatting input

On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: > Quoting PEP 3101: > > An example of the 'getitem' syntax: > >"My name is {0[name]}".format(dict(name='Fred')) > > It should be noted that the use of 'getitem' within a format string > is much more limited than its conventional usage. In

Re: [Python-Dev] Fwd: deep question re dict as formatting input

Quoting PEP 3101: An example of the 'getitem' syntax: "My name is {0[name]}".format(dict(name='Fred')) It should be noted that the use of 'getitem' within a format string is much more limited than its conventional usage. In the above example, the string 'name' really is the literal str

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, 22 Feb 2011 18:08:01 -0500 Alexander Belopolsky wrote: > On Mon, Feb 21, 2011 at 6:34 PM, David Claridge wrote: > .. > > I was wondering if there is some reason why C API functions like > > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > > rather than const char*s? >

Re: [Python-Dev] Fwd: deep question re dict as formatting input

On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: > ... It would appear from tests > that "{0[X]}".format(...) first tries to convert the string "X" to in > integer. If it succeeds then __getitem__() is called with the integer as an > argument, otherwise it is called with the string itself as a

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> If you compile > > #include > > int main() > { >    PyObject_CallMethod(0, "stdin", "stdin"); > } > > you get > > a.cc: In function ‘int main()’: > a.cc:5: warning: deprecated conversion from string constant to ‘char*’ > a.cc:5: warning: deprecated conversion from string constant to ‘char*’ > >

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Mon, Feb 21, 2011 at 6:34 PM, David Claridge wrote: .. > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? The later is addressed by issue 1699259

[Python-Dev] Fwd: deep question re dict as formatting input

One of the students on an introductory Python 3 class asks a very good question about string formatting. This could be because the course materials are misleading, so I would like to understand. It would appear from tests that "{0[X]}".format(...) first tries to convert the string "X" to in inte

Re: [Python-Dev] %-formatting depracation

On Wed, Feb 23, 2011 at 8:03 AM, Antoine Pitrou wrote: > I think there are many people still finding %-style more practical for > simple uses, A lot of the sting went out of that objection when field autonumbering was added to new-style formatting ("'%s' % (obj,)" vs "'{}'.format(obj)" as the min

Re: [Python-Dev] %-formatting depracation

> The very long term view is for %-formatting to go away Add to that that this view isn't universally shared among contributors. Many of us would rather see % formatting stay indefinitely. I regularly use it for new code. Regards, Martin ___ Python-Dev

Re: [Python-Dev] Const-correctness in C-API Object Protocol

>> Though I do not get that warning -- which compiler and version issues >> it? Is it a C or a C++ compiler? > > Well, which warning are you talking about? I think Guido assumed that the OP was getting actual complaints from some actual compiler - else he wouldn't have asked the question. However

Re: [Python-Dev] %-formatting depracation

On Wed, 23 Feb 2011 07:52:23 +1000 Nick Coghlan wrote: > On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > > The very long term view is for %-formatting to go away, but that's as far as > > the thinking has gone. There are currently no plans to introduce any > > deprecation warning, and I h

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> Also changing it now would be a giant hassle, leading to so-called > "const poisoning" where many, many APIs need to be changed before > everything would again work. We have been adding const to many places over the years. I think the specific case was just missed (i.e. nobody cared about adding

Re: [Python-Dev] %-formatting depracation

On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > The very long term view is for %-formatting to go away, but that's as far as > the thinking has gone. There are currently no plans to introduce any > deprecation warning, and I highly doubt we will even remove the feature in > Python 3, giving

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, Feb 22, 2011 at 1:17 PM, Xavier Morel wrote: > On 2011-02-22, at 21:55 , Antoine Pitrou wrote: >> On Tue, 22 Feb 2011 21:48:51 +0100 >> Stefan Behnel wrote: >>> Reid Kleckner, 22.02.2011 21:21: On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: > Also changing it now would be a g

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On 2011-02-22, at 21:55 , Antoine Pitrou wrote: > On Tue, 22 Feb 2011 21:48:51 +0100 > Stefan Behnel wrote: >> Reid Kleckner, 22.02.2011 21:21: >>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: Also changing it now would be a giant hassle, leading to so-called "const poisoning" wher

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, 22 Feb 2011 21:48:51 +0100 Stefan Behnel wrote: > Reid Kleckner, 22.02.2011 21:21: > > On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: > >> Also changing it now would be a giant hassle, leading to so-called "const > >> poisoning" where many, many APIs need to be changed before everythin

Re: [Python-Dev] Const-correctness in C-API Object Protocol

Reid Kleckner, 22.02.2011 21:21: On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: Also changing it now would be a giant hassle, leading to so-called "const poisoning" where many, many APIs need to be changed before everything would again work. The poisoning will not break any users of the AP

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: > Also changing it now would be a giant hassle, leading to so-called "const > poisoning" where many, many APIs need to be changed before everything would > again work. The poisoning will not break any users of the API, though, since they can pass

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, 22 Feb 2011 11:06:41 -0800 Guido van Rossum wrote: > > > > Probably because (a) the person who first wrote them used char* instead of > > const char*, and (b) it gives us API flexibility by not promising to not > > alter the char array at some point in the future. > > I'm sorry, but (b) d

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On 02/22/2011 01:55 PM, Brett Cannon wrote: On Mon, Feb 21, 2011 at 15:34, David Claridge mailto:da...@daave.com>> wrote: Hi, I was wondering if there is some reason why C API functions like PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments rather than const c

Re: [Python-Dev] %-formatting depracation

On 02/22/2011 01:43 PM, Ethan Furman wrote: Greetings! According to these release notes in Python 3.0, %-formatting will be going away. http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting However, I was unable to find any further evidence of ac

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Tue, Feb 22, 2011 at 10:55 AM, Brett Cannon wrote: > > > On Mon, Feb 21, 2011 at 15:34, David Claridge wrote: >> >> Hi, >> >> I was wondering if there is some reason why C API functions like >> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments >> rather than const char*s? If t

Re: [Python-Dev] %-formatting depracation

On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote: > Greetings! > > According to these release notes in Python 3.0, %-formatting will be going > away. > > > http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting > > > However, I was unable to find any

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Mon, Feb 21, 2011 at 15:34, David Claridge wrote: > Hi, > > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? If there is some reason these methods will > modify their string argumen

[Python-Dev] %-formatting depracation

Greetings! According to these release notes in Python 3.0, %-formatting will be going away. http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting However, I was unable to find any further evidence of actual deprecation in 3.1 or 3.2... does any

Re: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/22/2011 9:41 AM, anatoly techtonik wrote: > On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman wrote: >> On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: >>> Do you have a public list of stuff to be done (i.e. Roadmap)? >>> BTW, what is the

Re: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday)

On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman wrote: > On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: >> Do you have a public list of stuff to be done (i.e. Roadmap)? >> BTW, what is the size of Mercurial clone for Python repository? > > There is a TODO file in the pymigr repo (though

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/02/11 15:32, Eli Bendersky wrote: >> PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy >> migrating my projects to 3.2 (it was my compromise two years ago :), I >> don't have time to debug this :). >> > > I hope you do have

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

> PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy > migrating my projects to 3.2 (it was my compromise two years ago :), I > don't have time to debug this :). > I hope you do have a time to open an issue, though :-) Eli ___ Python-

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/02/11 13:20, Michael Foord wrote: >> Traceback (most recent call last): >>File "", line 1, in >> ValueError: operation forbidden on released memoryview object > > That seems like an odd error, but the decision was made that Python 2 > byte-s

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

On Tue, 22 Feb 2011 13:14:18 +0100 Jesus Cea wrote: > > This seems to be a bug in Python 3.2. Any suggestion?. Report an issue and investigate :) Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyth

Re: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

On 22/02/2011 12:14, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 10MB pickled structure generated in Python 2.7. I only use basic types (no clases) like sets, dictionaries, lists, strings, etc. The pickle stores a lot of strings. Some of them should be "bytes", while o

[Python-Dev] Strange error importing a Pickle from 2.7 to 3.2

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 10MB pickled structure generated in Python 2.7. I only use basic types (no clases) like sets, dictionaries, lists, strings, etc. The pickle stores a lot of strings. Some of them should be "bytes", while other should be "unicode". My idea is to