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 preferred
On Thu, Jan 22, 2009 at 10:16 PM, Mark Hammond wrote:
> On 23/01/2009 7:01 AM, Luke Kenneth Casson Leighton wrote:
>>>
>>> That doesn't really matter, I guess. An extension module build by your
>>> port will either fail to load into the regular Python (if
>>> libpython2.5.dll is not found), or loa
On Fri, Jan 23, 2009 at 6:36 AM, Luke Kenneth Casson Leighton
wrote:
> On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" wrote:
>>> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
>>> python25.dll (or libpython2.N.dll and python2N.dll) will they?
>>
>> Of course they will!
On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" wrote:
>> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
>> python25.dll (or libpython2.N.dll and python2N.dll) will they?
>
> Of course they will!
yeah, silly - i worked that out juust after i pressed "send".
> python.e
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.
Because there are four authors handling corrections it is a little
different than normal on who you
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 preferred instead.
I'm far from bein
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.
Once, CPython didn't have GC at all (apart from refcounting). Now it
does.
Giovanni Bajo wrote:
> On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
>
>> I regularly point out in code reviews that the very convenient and
>> common idiom of open(name, 'w').write(data) doesn't guarantee when the
>> file will be closed; its up to the GC implementation details.
>
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote:
> On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
>
>> I regularly point out in code reviews that the very convenient and
>> common idiom of open(name, 'w').write(data) doesn't guarantee when the
>> file will be closed; its up to th
On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote:
> I regularly point out in code reviews that the very convenient and
> common idiom of open(name, 'w').write(data) doesn't guarantee when the
> file will be closed; its up to the GC implementation details.
Which, to me, sounds like "ple
Luke Kenneth Casson Leighton wrote:
version. I hope that users will understand that it is disjoint from
the python.org version (as they seem to understand fine for the
Cygwin build, which already picks up its extension modules also from
a disjoint location, which helps to keep the two separate).
Luke Kenneth Casson Leighton wrote:
On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" wrote:
ok, so - different from what's being generated by ./configure under
msys under wine or native win32 - what's being generated (libpython 2
. 5 . a and libpython 2 . 5 . dll . a) is more akin to the cyg
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
There is result from pystone test test run an old PC (NT 5.1):
- 2.6(official build):
42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1
average=42429,4
deviation=311,6
- 2.6.1(official build):
35612,1; 35778,8; 35666,
On 23/01/2009 7:01 AM, Luke Kenneth Casson Leighton wrote:
That doesn't really matter, I guess. An extension module build by your
port will either fail to load into the regular Python (if
libpython2.5.dll is not found), or load and then crash (because it uses
a different copy of the Python runtim
On Thu, Jan 22, 2009 at 8:50 PM, "Martin v. Löwis" wrote:
>> I do not know alternative OpenID implementation for Python, so the
>> only way I see to continue development is to fork the lib.
>
> PyPI reports 15 packages when you search for OpenID. Not sure whether
> any of these are any good.
djan
> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
> python25.dll (or libpython2.N.dll and python2N.dll) will they?
Of course they will! 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
On Thu, Jan 22, 2009 at 8:22 PM, "Martin v. Löwis" wrote:
>>> This doesn't seem to be distributing binaries.
>>
>> sourceforge page. i checked the statistics, there don't seem to be
>> very many hits (sorry to hear that don, if you're reading this!) ok.
>> there _is_ a sourceforge page,... yep,
On Thu, Jan 22, 2009 at 8:17 PM, "Martin v. Löwis" wrote:
>> am i right?
>
> You should test that. I'm not sure whether it will crash (in particular,
> it might not on load), but it *might* crash, or fail in strange ways
> (e.g. when it checks whether something is a string, and decides it is
> no
I cannot find that the documentation states "with negative step swap
left with right". This is perhaps non-obvious. It is the words of the
tutorial that caused issue 5029 author's confusion. 'a'[0::-1] != []
(is True, author expected False).
The tutorial says:
"One way to remember how slices wo
>> This doesn't seem to be distributing binaries.
>
> sourceforge page. i checked the statistics, there don't seem to be
> very many hits (sorry to hear that don, if you're reading this!) ok.
> there _is_ a sourceforge page,... yep, downloads here:
>
> http://sourceforge.net/project/showfiles.
> am i right?
You should test that. I'm not sure whether it will crash (in particular,
it might not on load), but it *might* crash, or fail in strange ways
(e.g. when it checks whether something is a string, and decides it is
not, because it is looking at the other PyString_Type)
> and if _that'
On Thu, Jan 22, 2009 at 7:40 PM, "Martin v. Löwis" wrote:
>> there are already no less than _four_ mingw ports of python, of varying
>> degrees.
>>
>> * http://jove.prohosting.com/iwave/ipython/pyMinGW.html
>
> Ok, this one builds pythonXY, so it tries to be compatible with the
> official distrib
> That doesn't really matter, I guess. An extension module build by your
> port will either fail to load into the regular Python (if
> libpython2.5.dll is not found), or load and then crash (because it uses
> a different copy of the Python runtime). Likewise vice versa.
excellent, excellent that
> there are already no less than _four_ mingw ports of python, of varying
> degrees.
>
> * http://jove.prohosting.com/iwave/ipython/pyMinGW.html
Ok, this one builds pythonXY, so it tries to be compatible with the
official distribution (although it seems to link against MSVCRT.dll)
> * http://se
> version. I hope that users will understand that it is disjoint from
> the python.org version (as they seem to understand fine for the
> Cygwin build, which already picks up its extension modules also from
> a disjoint location, which helps to keep the two separate).
yes i made the default insta
Jesse> The other day, Martin pointed out that my buildslave had gone off
Jesse> the reservation: on restarting it via the "buildbot start
Jesse> ~/buildarea" command - Martin noticed the slave had started
Jesse> throwing the DNS resolution error:
...
Thanks for this. This app
On Thu, Jan 22, 2009 at 6:43 PM, "Martin v. Löwis" wrote:
>>> I can't comment on that, because I don't know what your port does.
>>> Does it not produce a .dll containing the majority of Python?
>>
>> no, it contains the minimal necessary amount of python modules,
>> exactly like when python is b
The other day, Martin pointed out that my buildslave had gone off the
reservation: on restarting it via the "buildbot start ~/buildarea"
command - Martin noticed the slave had started throwing the DNS
resolution error:
closing stdin
using PTY: True
svn: PROPFIND request failed on '/projects/pyth
> I do not know alternative OpenID implementation for Python, so the
> only way I see to continue development is to fork the lib.
PyPI reports 15 packages when you search for OpenID. Not sure whether
any of these are any good.
Regards,
Martin
___
Python
>> I can't comment on that, because I don't know what your port does.
>> Does it not produce a .dll containing the majority of Python?
>
> no, it contains the minimal necessary amount of python modules,
> exactly like when python is built using cygwin. actualy, there's a
> few modules that _have
Brett Cannon schrieb:
> 4. The var directive is not working even though the docs list it as a
> valid directive; so is it still valid and something is broken, or the
> docs need to be updated?
(First, you're confusing "directive" and "role" which led to some confusion
on
On Thu, Jan 22, 2009 at 10:12, Georg Brandl wrote:
> Brett Cannon schrieb:
>
3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [,
c=None]])``) really necessary when default argument values are
present? And do we really need to nest the brackets when it is obvious
>>
Brett Cannon schrieb:
>>> 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [,
>>> c=None]])``) really necessary when default argument values are
>>> present? And do we really need to nest the brackets when it is obvious
>>> that having on optional argument means the rest are opti
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 better use SCons
I do have some old patches for roundup that I was unable to test,
because of blocking issues with openidenabled python-openid library
and my Blogger server. See the top issue with the patch at
openidenabled tracker:
http://trac.openidenabled.com/trac/query?status=new&status=assigned&status=reopene
On 22 Jan 2009, at 12:42 , Nick Coghlan wrote:
Tino Wildenhain wrote:
g=(i for i in xrange(1000))[2:5]
g.next() # wrapper would now step 2 times w/o yield and 1 with
yield
2
g.next()
3
g.next()
4
g.next()
Traceback (most recent call last):
File "", line 1, in
StopIteration
as expecte
Nick Coghlan wrote:
Tino Wildenhain wrote:
g=(i for i in xrange(1000))[2:5]
g.next() # wrapper would now step 2 times w/o yield and 1 with yield
2
g.next()
3
g.next()
4
g.next()
Traceback (most recent call last):
File "", line 1, in
StopIteration
as expected - this could be included i
Tino Wildenhain wrote:
>>> g=(i for i in xrange(1000))[2:5]
>>> g.next() # wrapper would now step 2 times w/o yield and 1 with yield
> 2
>>> g.next()
> 3
>>> g.next()
> 4
>>> g.next()
> Traceback (most recent call last):
> File "", line 1, in
> StopIteration
>
> as expected - this could be incl
Hi,
Gerald Britton wrote:
The sieve is just one example. The basic idea is that for some
infinite generator (even a very simple one) you want to cut it off
after some point. As for the number of characters, I spelled lambda
incorrectly (left out a b) and there should be a space after the colon
On Thu, Jan 22, 2009 at 9:18 AM, Amaury Forgeot d'Arc
wrote:
>> or, is the .pyd loading a bit cleverer (or perhaps a bit less
>> cleverer) than i'm expecting it to be?
>
> On Windows, you must turn on the --enable_shared option if you want to
> build extension modules.
> You could take the cygwin
On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" wrote:
>> ok, so - different from what's being generated by ./configure under
>> msys under wine or native win32 - what's being generated (libpython 2
>> . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin
>> environment.
>>
>> ther
Hello,
On Wed, Jan 21, 2009 at 22:07, Luke Kenneth Casson Leighton
wrote:
> On Wed, Jan 21, 2009 at 7:42 PM, "Martin v. Löwis" wrote:
>>> sorry, martin - i thought the win32 builds generated python25.lib,
>>> python25.dll
>>
>> Correct.
>>
>>> and python25.def
>>
>> No.
>>
>>> so as to fit into
Terry Reedy wrote:
Cameron Simpson wrote:
Back at uni we had to implement a small language in our compilers class
and the lecturer had specified a proper generic while loop, thus:
loop:
suite
while invariant
suite
endloop
In Python, that is spelled
while True:
suite
if not
43 matches
Mail list logo
