On Mon, Jan 2, 2012 at 10:53 PM, Alexey Borzenkov wrote:
> On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes wrote:
>> Am 02.01.2012 06:55, schrieb Paul McMillan:
>>> I think Ruby uses FNV-1 with a salt, making it less vulnerable to
>>> this. FNV is otherwise similar to
On Mon, Jan 2, 2012 at 7:18 PM, Christian Heimes wrote:
> Am 02.01.2012 06:55, schrieb Paul McMillan:
>> I think Ruby uses FNV-1 with a salt, making it less vulnerable to
>> this. FNV is otherwise similar to our existing hash function.
>>
>> For the record, cryptographically strong hash functions
On Thu, Mar 6, 2008 at 3:52 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Mingw tends to be rather more stable (though not itself without the
> occasional library compatibility issue), and more freely available.
Not all extensions can be built using mingw (pywin32 comes to mind
immediately). And
Hi everyone,
Some time ago I've stumbled upon a problem with compiling py2exe with
mingw: it resulted in invalid executable run.exe. At first I dismissed
it as some very strange problem, but recently I decided to look into
it again and found that the reason for this is a .def file, supplied
during
> C:\>1.py
> hStdOut: 0007
> Something
>
> C:\>1.py>1.txt
> hStdOut: 0004
>
> (1.txt file is now completely empty, i.e. hStdOut is invalid)
Hmm, now I see that maybe that's where I was wrong. When I used
`python 1.py>1.txt' it suddenly started working as expected. :
On 8/23/07, Mark Hammond <[EMAIL PROTECTED]> wrote:
> > Further investigations showed that it seems to be some strange OS
> > quirk/bug,
> I'm not quite with you here - what strange OS bug do you think you have
> found? I expect that such a bug would be well documented somewhere, even if
> not dir
For a long time I was surprised why if I have a script testme.py:
import subprocess
subprocess.call("echo Something", shell=True)
and I try to execute it like this:
python testme.py >testme.txt
I get the output:
The handle is invalid.
Strange failures randomly happened with di
On 6/11/07, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> The problem is that I don't know if anything actually supports bit 11
> at the time and can't even tell if I did this correctly or not. :(
I downloaded the latest WinZip and can confirm that it parses utf-8
filenames
On 6/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> For compatibility, I would propose to use UTF-8 only if the file
> name is not ASCII. Even though the OEM code pages vary, they
> are (mostly) ASCII supersets. So if the string can be encoded
> in ASCII, there is no need to set the UTF-8 fl
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > So the general idea is that at least directory filename has some sort
> > of convention of using oem (dos, console) encoding on Windows, cp866
> > in my case. Header filenames have different encodings, and seem to be
> > ignored.
> Ok, th
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I don't think always encoding them to utf-8 (and using bit 11 of
> > flag_bits) is a good idea, since there's a chance to create archives
> > that won't be correctly readable by programs not supporting this bit
> > (it's no secret that cu
> Current zipfile seems to officially support ascii filenames only
> anyway, so the patch can be as simple as this:
Submitted patch and test case as http://python.org/sf/1734346
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
> > Also note that I'm trying to ask if zipfile should be improved, how it
> > should be improved, and this possible improvement is not even for me
> > (because now I know how zipfile behaves and I will work correctly with
> > it, but someone else might stumble upon this very unexpectedly).
> If yo
Hi everyone,
Today I've stumbled upon a bug in my program that wasn't very
straightforward to understand. The problem is that I was passing
unicode filenames to zipfile.ZipFile.write and I had
sys.setdefaultencoding() in effect, which resulted in a situation
where most of the bytes generated in zi
On 5/23/07, Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote:
> > > Install in the ProgramFiles folder.
> > Only over my dead body. *This* is silly.
> Bill doesn't think so. And he gets to decide. I mean we do want
> to play nice, don't we? Nothing installs itself in the root anymore,
> not sinc
On 4/30/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Python initially inherited its parsing from C. While this has
> been generally useful, there are some remnants which have been
> less useful for python, and should be eliminated.
>
> + Implicit String concatenation
>
> + Line
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> That code only tests it for pagefile.sys. My question was about open
> handles in general. Both Calvin Spealman and I found that you cannot
> reproduce the problem when you, in Python 2.5.0, open a file, and then
> try to os.stat() it - even
On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > After doing some research I found that it seems to be impossible to
> > use CreateFile for a file that doesn't have SHARE_READ. I played with
> > different combinations and with FLAG_BACKUP_SEMANTICS and nothing
> > helped. However on Wind
Hi Martin,
On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The error Windows reports is ERROR_SHARING_VIOLATION. I never
> understood sharing fully, but it may be that if the file is opened
> in "exclusive sharing", stat'ing it may fail.
Sharing is actually very easy. If you didn't spe
On 4/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > What if someone passes a callable that doesn't have the expected
> > > signature?
> > Well, I don't know a way to catch such situations now, so removing
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > assert hasattr(x, '__call__')
> >
> > I note that callable() was introduced before all callable objects had
> > a __call__ attribute. This is no longer the case, so it's not needed.
> I just didn't think about that possibility. If that work
On 3/8/07, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> On 3/7/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Now it's becoming difficult: several people in favor, some opposed...
> > W
On 3/7/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Now it's becoming difficult: several people in favor, some opposed...
> What about changing the semantics of splitext and creating a new
> function (available on all platforms) that does what the
On 1/24/07, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
[Alexey:]
> I think that's the right thing to do, because that is mathematically
> correct. j is just an imaginary number with a property that j*j = -1. So
> (a+bj) + (c+dj)j = (a-d) + (b+c)j.
Yes, thanks, I know what j is, and I know how
On 1/24/07, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> >>> complex(complex(1.0, 2.0), complex(10.0, 20.0))
>
> (-19+12j)
>
> WTF? In any case, that's also what's destroying the sign of the
> imaginary part in complex(1.0, -0.0).
It seems pretty clear what it thinks it's doing -- namely,
def
On 12/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
With the proper mapping, this is trivial...
class namelookup:
[...snip...]
foo = foo()
>>> print "%(foo.b)i + %(foo.a)i"%namelookup(locals())
2 + 1
>>>
It can even be simpler and more powerful:
class evallookup:
def __init__(self
On 10/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> any reason you cannot just use the "subprocess" module instead, like
> everyone else?
Oh! Wow! I just simply didn't know of its existance (I'm pretty much
new to python), and both distutils and SCons (I was looking inside
them because they ar
Forgot to include python-dev...
On 10/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Umm... do you mean that spawn*p* on python 2.5 is an absolute no?
> Yes. No new features can be added to Python 2.5.x; Python 2.5 has
> already been released.
Ugh... that's just not fair. Because of this
On 10/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Please consider also exposing _wspawnvp, depending on whether path
> argument is a Unicode object or not. See PEP 277 for guidance.
> Since this would go into 2.6, support for Windows 95 isn't mandatory.
Umm... do you mean that spawn*p* o
On 10/12/06, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> At least when I did it with my copy, nt.spawnvp seems to work fine...
Hi everyone again. I've created patch for spawn*p*, as well as for
exec*p* against trunk, so that when possible it uses crt's execvp[e]
(defined
Hi all,
I've been looking at python 2.5 today and what I notices is absense of
spawnvp with this comment in os.py:
# At the moment, Windows doesn't implement spawnvp[e],
# so it won't have spawnlp[e] either.
I'm wondering, why so? Searching MSDN I can see that these functions
are implemented
31 matches
Mail list logo
