Brett Cannon wrote:
> On Fri, Jan 23, 2009 at 12:11, Steven Bethard
> wrote:
>> On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis"
>> wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
>>> Nice! So it's bzr, as my machine just told me (after adding
>>> the s
Guido van Rossum wrote:
On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy wrote:
While a strong argument can be made that the remaining 2.x versions should
not be changed, they do not apply to 3.x. New code and ported old code
should use 'with' wherever quick closing needs to be guaranteed. The
Brett Cannon wrote:
On Fri, Jan 23, 2009 at 13:39, Paul Moore wrote:
I'm not sure I'm
comfortable with sitting back and waiting to quite that extent (I'm
*already* biting my tongue over some of Brett's comments with which I
strongly disagree), but I'd rather not have the PEP dissolve in a
flam
[SNIP]
No, Python 2.5 is linked with msvcr71.dll.
ehn? i don't see that anywhere in any PC/* files - i do see that
there's a dependency on .NET SDK 1.1 which uses msvcr71.dll
Take a look at PCbuild/pythoncore.vcproj. It says
Version="7.10"
This is how you know VS 2003 was used to bu
Luke Kenneth Casson Leighton wrote:
[SNIP]
python.exe (say, the official one) loads
python25.dll. Then, an import is made of a ming-wine extension, say
foo.pyd, which is linked with libpython2.5.dll, which then gets loaded.
Voila, you have two interpreters in memory, with different type objects,
Hi,
for http://bugs.python.org/issue4863
If no one objects, I am going to remove the mwerkscompiler module from
distutils without any deprecation process, as Martin suggested
(since it is linked into ccompiler with "mac" for the os.name)
Now the question is, should I add a ticket to deprecate ma
On Fri, Jan 23, 2009 at 12:52 PM, Terry Reedy wrote:
> Giovanni Bajo wrote:
>>
>>> You are so very wrong, my son. CPython's implementation strategy
>>> *will* evolve. Several groups are hard at work trying to make a faster
>>> Python interpreter, and when they succeed, everyone, including you,
>>>
anatoly techtonik wrote:
On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov
wrote:
Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.
No it was complete but use SCons. Most of changes changes in code you will
see again in 3871.
I would be
rdmur...@bitdance.com wrote:
On Fri, 23 Jan 2009 at 21:23, "Martin v. L�wis" wrote:
Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.
However, an ftp server is different. It might start up wi
> I don't see how starting with an empty directory helps. The filename
> comes from the client, and the FTP server can't know what the actual
> encoding of that filename is.
Sure it can. If the client supports RFC 2640, it will send file names
in UTF-8. If the client does not support RFC 2640, th
On Fri, Jan 23, 2009 at 13:39, Paul Moore wrote:
> 2009/1/23 "Martin v. Löwis" :
>>> Brett mentioned in his email that he wasn't ready to make a decision yet, I
>>> think? I also think that the PEP could still use some modifications from
>>> people
>>> who have more experience with the DVCSs.
>>
2009/1/23 "Martin v. Löwis" :
>> Brett mentioned in his email that he wasn't ready to make a decision yet, I
>> think? I also think that the PEP could still use some modifications from
>> people
>> who have more experience with the DVCSs.
>
> My question really was whether it is already ready for
On Fri, 23 Jan 2009 at 21:23, "Martin v. L?wis" wrote:
Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.
However, an ftp server is different. It might start up with an empty
folder, and receiv
Giovanni Bajo wrote:
You are so very wrong, my son. CPython's implementation strategy
*will* evolve. Several groups are hard at work trying to make a faster
Python interpreter, and when they succeed, everyone, including you,
will want to use their version (or their version may simply *be* the
n
On Fri, Jan 23, 2009 at 11:54:38AM -0800, Toshio Kuratomi wrote:
> AFAIK, Apache is in the same boat as ftp servers. You're thinking of
> the encoding inside of the files. The problem is with the file names
> themselves.
Mostly yes. But Apache is so powerful I can do (and really did) a lot of
> Given that a Unix OS can't know what encoding a filename is in (*),
> I can't see that one could practically implement a Unix FTP server
> in any other way.
However, an ftp server is different. It might start up with an empty
folder, and receive *all* of its files through upload. Then it can
cer
> Brett mentioned in his email that he wasn't ready to make a decision yet, I
> think? I also think that the PEP could still use some modifications from
> people
> who have more experience with the DVCSs.
My question really was whether it is already ready for the wider
audience up for discussion
> Just a short update on my porting issues. I tried various things in the
> holidays/vacation, filed several bug reports, got a few patches applied and I
> think the thing is taking shape now. However, I couldn't work on it for the
> past two weeks since I'm just too swamped at work here. I have
On Fri, Jan 23, 2009 at 12:11, Steven Bethard wrote:
> On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis"
> wrote:
>>> import random
>>> print(random.choice('svn', 'bzr', 'hg', 'git'))
>>
>> Nice! So it's bzr, as my machine just told me (after adding
>> the square brackets).
>
> Wow, th
On Fri, Jan 23, 2009 at 12:06 PM, "Martin v. Löwis" wrote:
>> import random
>> print(random.choice('svn', 'bzr', 'hg', 'git'))
>
> Nice! So it's bzr, as my machine just told me (after adding
> the square brackets).
Wow, that decision was a lot easier than I thought it would be. ;-)
Steve
> import random
> print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
Oleg Broytmann wrote:
> On Fri, Jan 23, 2009 at 02:35:01PM -0500, rdmur...@bitdance.com wrote:
>> Given that a Unix OS can't know what encoding a filename is in (*),
>> I can't see that one could practically implement a Unix FTP server
>> in any other way.
>
>Can you believe there is a well-kn
Tony, you are posting internal communications to python-dev!!!
On Fri, Jan 23, 2009 at 11:09 AM, Tony Lownds wrote:
> Hi Paulus,
> Have you fixed these aerts before? We need a script to fix these alerts.
> Thanks
> -Tony
>
> Begin forwarded message:
>
> From: support+...@pagedna.com
> Date: Janua
On Fri, Jan 23, 2009 at 02:35:01PM -0500, rdmur...@bitdance.com wrote:
> Given that a Unix OS can't know what encoding a filename is in (*),
> I can't see that one could practically implement a Unix FTP server
> in any other way.
Can you believe there is a well-known program that solved the iss
Hi Paulus,
Have you fixed these aerts before? We need a script to fix these alerts.
Thanks
-Tony
Begin forwarded message:
From: support+...@pagedna.com
Date: January 23, 2009 11:00:01 AM PST
To: probl...@pagedna.com
Subject: [ALERT] cityoftoronto: problem saving to products table
problem sav
Uh, Tony, I think you sent this to the wrong email address. =)
On Fri, Jan 23, 2009 at 11:22, Tony Lownds wrote:
> Rob and/or Tim,
> Can you track this down?
> Thanks
> -Tony
>
> Begin forwarded message:
>
> From: support+...@pagedna.com
> Date: January 23, 2009 11:16:26 AM PST
> To: probl...@pa
On Fri, 23 Jan 2009 at 21:55, Oleg Broytmann wrote:
On Fri, Jan 23, 2009 at 10:15:18AM -0800, Brett Cannon wrote:
If I remember correctly something along Martin's comment about 7-bit
clean is needed, but some servers don't follow the standard, so I
swapped it to Latin-1. But that was so long ago
Rob and/or Tim,
Can you track this down?
Thanks
-Tony
Begin forwarded message:
From: support+...@pagedna.com
Date: January 23, 2009 11:16:26 AM PST
To: probl...@pagedna.com
Subject: [ALERT] cbank: OldHashChecker cannot check password, uid is
None
OldHashChecker cannot check password, uid
On Fri, Jan 23, 2009 at 10:15:18AM -0800, Brett Cannon wrote:
> If I remember correctly something along Martin's comment about 7-bit
> clean is needed, but some servers don't follow the standard, so I
> swapped it to Latin-1. But that was so long ago I don't remember where
> I gleaned the details f
On Fri, Jan 23, 2009 at 07:30, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brett, thanks for putting this PEP together!
>
Yep. Just make sure I don't do something like this for a LONG time.
Apparently I didn't learn my lesson after the issue tracker migration.
> On
On Fri, Jan 23, 2009 at 03:05, Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>>
>> I have now converted PEP 374
>> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
>> and checked it in. I am not going to paste it into an email as it is
>> nearly 1500 lines in reST fo
On Fri, Jan 23, 2009 at 00:39, "Martin v. Löwis" wrote:
>> And I would like to thank my co-authors for their time and effort thus
>> far in filling in the PEP on behalf of their favorite DVCS. Everyone
>> has put in a lot of time already with I am sure more time in the
>> future.
>
> So what will
On Fri, Jan 23, 2009 at 00:31, "Martin v. Löwis" wrote:
> Giampaolo Rodola' wrote:
>> Hi,
>> while attempting to port pyftpdlib [1] to Python 3 I have noticed that
>> ftplib differs from the previous 2.x version in that it uses latin-1
>> to encode everything it's sent over the FTP command channel
ACTIVITY SUMMARY (01/16/09 - 01/23/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2322 open (+42) / 14538 closed (+32) / 16860 total (+74)
Open issues with patches: 790
Average
Giovanni Bajo wrote:
> On 1/23/2009 4:27 PM, Guido van Rossum wrote:
>> On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
>>> I miss to understand why many Python developers are so fierce in trying
>>> to push the idea of cross-python compatibility (which is something that
>>> does simply *not
Guido van Rossum python.org> writes:
>
> And, by the way, "for line in open(filename): ..." will continue to
> work. It may just not close the file right away. This is a forgivable
> sin in a small program that opens a few files only. It only becomes a
> program when this is itself inside a loop
On 1/23/2009 4:27 PM, Guido van Rossum wrote:
On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
I miss to understand why many Python developers are so fierce in trying
to push the idea of cross-python compatibility (which is something that
does simply *not* exist in real world for applicati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett, thanks for putting this PEP together!
On Jan 23, 2009, at 3:39 AM, Martin v. Löwis wrote:
Somebody will have to make a decision. Ultimately, Guido will have to
approve the PEP, but it might be that he refuses to make a choice of
specific DVC
On Fri, Jan 23, 2009 at 2:57 AM, Giovanni Bajo wrote:
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to warn about
> rainy days in the f
On Fri, 23 Jan 2009 at 11:57, Giovanni Bajo wrote:
The fact that file objects are collected and closed immediately in all
reasonable use cases (and even in case of exceptions, that you mention,
things get even better with the new semantic of the except clause) is a
*good* property of Python. I re
> That would be break so much code that I doubt that, in practice, you can
> slip it through within a release. Besides, being able to write simpler
> code like "for L in open("foo.txt")" is per-se a good reason *not to*
> put file objects in cycles; so you will probably need more than one good
> re
Giovanni Bajo develer.com> writes:
>
> The fact that file objects are collected and closed immediately in all
> reasonable use cases (and even in case of exceptions, that you mention,
> things get even better with the new semantic of the except clause)
The new except clause removes any external
Giovanni Bajo wrote:
> On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
[...]
> I miss to understand why many Python developers are so fierce in trying
> to push the idea of cross-python compatibility (which is something that
> does simply *not* exist in real world for applications) or to
Brett Cannon python.org> writes:
>
> I have now converted PEP 374
> (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST
> and checked it in. I am not going to paste it into an email as it is
> nearly 1500 lines in reST form.
It seems the ">>" token is mangled into a French closin
On gio, 2009-01-22 at 18:42 -0800, Guido van Rossum wrote:
> On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote:
> > CPython will always use reference counting and thus have a simple and
> > clear GC criteria that can be exploited to simplify the code.
>
> Believe this at your own peril.
>
> O
Martin v. Löwis v.loewis.de> writes:
> Somebody will have to make a decision. Ultimately, Guido will have to
> approve the PEP, but it might be that he refuses to make a choice of
> specific DVCS. Traditionally, it is the PEP author who makes all
> choices (considering suggestions from the communi
Hi!
Just a short update on my porting issues. I tried various things in the
holidays/vacation, filed several bug reports, got a few patches applied and I
think the thing is taking shape now. However, I couldn't work on it for the
past two weeks since I'm just too swamped at work here. I haven't
> And I would like to thank my co-authors for their time and effort thus
> far in filling in the PEP on behalf of their favorite DVCS. Everyone
> has put in a lot of time already with I am sure more time in the
> future.
So what will happen next? ISTM that the PEP is not complete, since it
doesn't
Giampaolo Rodola' wrote:
> Hi,
> while attempting to port pyftpdlib [1] to Python 3 I have noticed that
> ftplib differs from the previous 2.x version in that it uses latin-1
> to encode everything it's sent over the FTP command channel, but by
> reading RFC-2640 [2] it seems that UTF-8 should be p
On Fri, Jan 23, 2009 at 8:08 AM, "Martin v. Löwis" wrote:
>> ironically, i started out with the intent of going for python2N.dll
>> interoperability. then i noticed that all the other mingw ports
>> dropped the total-inclusion-of-all-modules because you _can_.
>
> What modules are built in
> ironically, i started out with the intent of going for python2N.dll
> interoperability. then i noticed that all the other mingw ports
> dropped the total-inclusion-of-all-modules because you _can_.
What modules are built in and what modules are external doesn't affect
interoperability wrt
> ok, there's a solution for that - the gist of the solution is already
> implemented in things like Apache Runtime and Apache2 (modules), and
> is an extremely common standard technique implemented in OS kernels.
> the "old school" name for it is "vector tables".
We might be able to do that in P
52 matches
Mail list logo
