Re: [Python-Dev] [RELEASE] Python 2.7.4 release candidate 1

[Hynek Schlawack]

Am 26.03.2013 um 23:05 schrieb Sean Felipe Wolfe :

>> Anyway, you should trust Brett Canon: "Python 3.3: Trust Me, It's
>> Better Than Python 2.7".
>> 
>> https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon
> Was there supposed to be audio with this, or is it slides only? I got
> no audio :P

Speakerdeck is slides only. The video is here: 
http://pyvideo.org/video/1730/python-33-trust-me-its-better-than-27

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

[Hynek Schlawack]

Am 04.12.2012 um 00:42 schrieb Gregory P. Smith :

> * How would we convert all the builtins to use Clinic?  I fear any
>   solution will involve some work by hand.  Even if we can automate
>   big chunks of it, fully automating it would require parsing arbitrary
>   C.  This seems like overkill for a one-shot conversion.
>   (Mark Shannon says he has some ideas.)
> 
> A lot of hand work.  Sprints at pycon.  etc.  Automating nice chunks of it 
> could be partially done for some easy cases such as things that only use 
> ParseTuple today.

I don’t see this as a big problem. There’s always lots of people who want to 
get into Python hacking and don’t know where to start. These are easily 
digestible pieces that can be *reviewed in a timely manner*, thus ideal. We 
could even do some (virtual) sprint just on that.

As for Larry: great approach, I’m impressed!___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)

[Hynek Schlawack]

Am 28.10.2012 um 12:11 schrieb Antoine Pitrou :

>> One word: profile.
>> 
>> Looking at stat counts alone rather than measuring the total time spent in
>> all types of system calls from strace and profiling is not really useful. ;)
> Agreed, but I can't seem to cope properly with gprof. Any suggestion?

http://oprofile.sourceforge.net/news/
http://valgrind.org/docs/manual/cl-manual.html

Are both useful.  gprof is virtually useless.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom

[Hynek Schlawack]

Am 16.10.2012 um 12:15 schrieb andrew.svetlov :

> +   For easy to use interface to system randomness please see
> +   :class:`random.SystemRandom`.

Is it just my non-native speaker ears, or should there be an “an” before “easy”?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed schedule for Python 3.4

[Hynek Schlawack]

Am 04.10.2012 um 03:38 schrieb R. David Murray :

>>> Other proposed large-scale changes:
>>> [...]
>>> * A standard event-loop interface (PEP by Jim Fulton pending)
>> 
>> Really? Was this discussed somewhere? I'd like to know more about it.
> 
> I believe it was discussed at the Language Summit at the last Pycon.
> As I recall there was at least one other person interested in helping
> with it, but I don't remember who.

T’was lvh and I remember doing some cheap spelling checking on it back at 
EuroPython 20_11_ but the work seems to has stalled 9 months ago.

Adding him to the loop.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Infrastructure] Buildbot master moved

[Hynek Schlawack]

> Now someone needs to incorporate these changes into our local git. I'm a
> git newbie, and basic commands seem to fail for me:
> 
> $ git fetch -v
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
> 
> Hynek, do you want to help?

I'd love to, but I'm afk for the rest of the (CEST) day. :( If it's broken 
still broken tomorrow, you know where to find me. :)

Cheers,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Infrastructure] Buildbot master moved

[Hynek Schlawack]

Hi,

I don’t know if it’s known, but the bot infrastructure is FUBAR now.
http://buildbot.python.org/all/waterfall is a stacktrace and all tests
fail because of the XML-RPC tests that use our buildbot API.

Regards
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Signed packages

[Hynek Schlawack]

Am 23.06.12 14:03, schrieb mar...@v.loewis.de:

>> I'm surprised gpg hasn't been mentioned here.  I think these are all
>> solved problems, most free software that is signed signs it with the
>> gpg key of the author.  In that case all that is needed is that the
>> cheeseshop allows the uploading of the signature.
> For the record, the cheeseshop has been supporting pgp signatures
> for about ten years now. Several projects have been using that for
> quite a while in their releases.

Also for the record, it’s broken as of Python 3.2. See
http://bugs.python.org/issue10571
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: #4489: Add a shutil.rmtree that isn't suspectible to symlink attacks

[Hynek Schlawack]

>> It is used automatically on platforms supporting the necessary os.openat() 
>> and
>> os.unlinkat() functions. Main code by Martin von Löwis.
> 
> Unfortunately, this isn't actually having any effect at the moment
> since the os module APIs changed for the beta release.
> 
> The "hasattr(os, 'unlinkat')" and "hasattr(os, 'openat')" checks need
> to become "os.unlink in os.supports_dir_fd" and "os.open in
> os.supports_dir_fd", and the affected calls need to be updated to pass
> "dir_fd" as an argument to the normal versions of the functions.
> 
> At least we know the graceful fallback to the old behaviour is indeed
> graceful, though :)

Yeah I've been told on IRC already. I'll commit a fix in a few minutes
if my regression tests on OS X and Linux work fine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of packaging in 3.3

[Hynek Schlawack]

On 06/20, Antoine Pitrou wrote:

> Let's make things clear: packaging is suffering from a lack of
> developer involvement, 

Absolutely.

And to be more precise: solid hands-on leadership. Eric wrote it in his
original mail: both packaging maintainers are burned out/busy.  That’s a state
that is very unlikely to attract more developers – myself included.

> and a lack of user interest.

Maybe I'm getting you wrong here, but ISTM that proper packaging is in the
short list on nearly everybody’s “things I wish they'd fix in Python”.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] whither PEP 407 and 413 (release cycle PEPs)?

[Hynek Schlawack]

Am 03.06.12 13:22, schrieb "Martin v. Löwis":

> - Some contributors are worried about getting their contributions "out",
>   and some core committers are worried that we get fewer contributions
>   because of that.
> 
>   While I well recall the feeling of getting changes "out", the real
>   concerns only exist for the very first contribution:
>   * Those gurus on python-dev are certainly working on a fix for this
> very important issue already, how could they not have noticed?
> My work will be futile, and they'll fix it the day before I submit
> the patch.
>   * Now that the patch is uploaded, can somebody *please* review it?
> How hard can it be to look over 20 lines of code?
>   * Now that they committed it, when can I start telling my friends
> about it? The next release takes ages, and waiting is not fun.
> 
>   While these concerns are all real, it's really a matter of contributor
>   education to deal with them, The longer people contribute to open
>   source (or participate in any kind of software development), the
>   more they learn that this is just how things work. The PEP really
>   only addresses the third concern, whereas I think that the second
>   is much more relevant.

As a newish core developer I’d like to stress that Martin is 100% right
here.

Point three was never an issue to me – the biggest satisfaction is
seeing the actual commit with the own name and the appearing in ACKS –
you _can_ already tell your friends/tweet/blog about it at this point.
And people do.

OTOH point two is _very_ frustrating. The most colorful bikeshed is
still much better than ignored patches. Personally, I gave up on CPython
after my patches languished for weeks until Antoine revived the tickets
three months later.

I'm sure we've lost plenty of talent this way already and _if_ we want
to attract more talented contributors, _this_ is the issue to tackle.
The release process has nothing to do with that.

I guess the PEPs (especially 413) are more about the bad rap the stdlib
has been getting lately (e.g.
).

>   As for us not getting enough contributions: can we please worry
>   about that when we have all patches processed that already have
>   been contributed?

Realistically, that means "never".

Cheers,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): #14804: Remove [] around optional arguments with default values

[Hynek Schlawack]

Hi Nick,

>> Mostly just mechanical removal of []. In some rare cases I've pulled the
>> default value up into the argument list.
> Be a little careful with this - "[]" is the right notation when the
> function doesn't support keyword arguments. At least one of the
> updated signatures is incorrect:

Ah dang, thanks for pointing this out! I went at least five times
through all changes but there had to be one thing I missed. :(

Same in dl.open() & ossaudiodev.oss_audio_device.setparameters(). I will
go through them all once more and fix it at the latest tomorrow.

Regards,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

[Hynek Schlawack]

>> Also -1 on docs3, that would suggest that it’s still something special
>> and 2 (= docs) is the real deal.
> Guido and I are proposing docs2 and docs3 each pointing to the latest
> docs for each series. That puts them on equal status.
> docs.python.org, besides being a namespace for specific version docs
> (/x.y, minus Nick's /latest) would be transitioned away from being a
> synonym for docs2. It could become a *neutral* index page listing docs2
> and docs3 for the 'latest' production version of each series and then
> each subdirectory.

I find docs2/3 ugly as it reminds me of load balancing (like
www1.python.org) and it also doesn’t really make sense to me. I have no
problem to have these DNS records and redirect them to docs.python.org/2
or /3 but I wouldn’t like them to be the canonical URIs.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

[Hynek Schlawack]

>>> Namespaces are a great idea, let's do more of those :)
>> A subdomain isn't a namespace?
> A subdomain is only a namespace if you use it as one. The following
> would be using docs.python.org as a namespace (and is what I think we
> should move towards):
> 
> docs.python.org/latest
> docs.python.org/dev
> docs.python.org/3.2
> docs.python.org/3.1
> docs.python.org/2.7
> docs.python.org/2.6
> etc...

Bikesheddingly, I’d prefer “stable” over ”latest”. That would also
better convey the point that 3 is ready for production.

Otherwise +1; I find the current hybrid structure suboptimal.

Also -1 on docs3, that would suggest that it’s still something special
and 2 (= docs) is the real deal.

Regards,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backward compatibility of shutil.rmtree

[Hynek Schlawack]

Am 20.05.12 23:46, schrieb mar...@v.loewis.de:

 Two of them differ in the new version: os.fwalk() is used instead of
 os.listdir() and os.unlinkat() instead of os.remove().
>>> It would be os.flistdir instead of os.listdir, not os.fwalk, right?
>> It’s actually os.fwalk. It has been implemented by Charles-François as a
>> dependency of the ticket because it seemed generally useful – therefore
>> I used it for the implementation.
> I think that's a mistake then, because of the limited error reporting.
> With os.fwalk, you don't know exactly what it is that failed, but it
> may be useful to know.

Well, as fwalk does only directory traversing, it means that something
went wrong while doing so. The exception should be more helpful at this
point, no?

> So I propose to duplicate the walking in rmtree.

I'm -1 on that one; the information gain doesn’t seem that big to me and
doing fwalk right isn't trivial (see
).

It’s easy to do a copy’n’paste now but the trade-off of having to
maintain both for a bit more of information from a high level function
doesn’t seem worth to me.

> I also wonder how exactly in your implementation directory handles
> get closed, and how that correlates to attempts at removing the
> directories.

Directory handles get closed inside of fwalk (try/finally) – but I think
it’s easier if you take a quick look yourself before I explain things to
you you didn’t want to know. :)

Regards,
Hynek


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backward compatibility of shutil.rmtree

[Hynek Schlawack]

>> Two of them differ in the new version: os.fwalk() is used instead of
>> os.listdir() and os.unlinkat() instead of os.remove().
> It would be os.flistdir instead of os.listdir, not os.fwalk, right?

It’s actually os.fwalk. It has been implemented by Charles-François as a
dependency of the ticket because it seemed generally useful – therefore
I used it for the implementation.

(There has been also been the idea to re-implement the default rmdir
with os.walk to make them more similar; but that's a different story.)

> The way this interface is defined, it's IMO best to do "precise"
> reporting, i.e. pass the exact function that caused the failure.
> I'd weaken the documentation to just specify that the error-causing
> function is reported, indicating that the exact set of functions
> may depend on the operating system and change across Python versions.

So you suggest to not mention all the possible functions at all? That
seems useful to me, as the list will (hopefully) grow anyway and nailing
it down is getting less useful with every new implementation.

Regards,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Backward compatibility of shutil.rmtree

[Hynek Schlawack]

Hi,

as our shutil.rmtree() is vulnerable to symlink attacks (see
) I’ve implemented a safe version
using os.fwalk() and os.unlinkat() for Python 3.3.

Now we face a problem I’d like a broad opinion on: rmtree has a callback
hook called `onerror` that that gets called with amongst others the
function that caused the error (see
).

Two of them differ in the new version: os.fwalk() is used instead of
os.listdir() and os.unlinkat() instead of os.remove().

The safe version is used transparently if available, so this could
potentially break code. Also it would mean that rmtree would behave
differently on Linux & OS X for example.

I’ve been thinking to "fake" the function names, as they map pretty good
anyway. I.e. call onerror with os.listdir if os.fwalk failed and with
os.remove instead of os.unlinkat. That could also make sense if some
kind soul writes a safe rmtree for Windows or OS X so the function works
the same across all platforms. It's a bit ugly though, a cleaner way
would be to start using well defined symbols, but that would break code
for sure.

Opinions?

Cheers,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

[Hynek Schlawack]

Hi,

> At what point should we cut over docs.python.org to point to the
> Python 3 documentation by default?  Wouldn't this be an easy bit to
> flip in order to promote Python 3 more better?

I’d vote for the release of 3.3 instead of a surprise change in the
middle of nowhere.

Cheers,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

[Hynek Schlawack]

Hi Georg,

Am 25.03.2012 um 08:34 schrieb Georg Brandl:

> Here's another try, mainly with default browser font size, more contrast and
> collapsible sidebar again:
> 
> http://www.python.org/~gbrandl/build/html2/

I really like it!

Only one nitpick: If a header follows on a “seealso”, the vertical rhythm is 
slightly broken like in https://skitch.com/hyneks/8c6j8/

Minor detail but should be easy to fix. :)

Cheers,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Hynek Schlawack]

Am 02.03.2012 um 20:44 schrieb Barry Warsaw:

>> 3.3 is the IMHO the first 3.x release that brings really cool stuff to the
>> table and might be the tipping point for people to start embracing Python 3 –
>> despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I
>> hope for some half-official back port there. :)
> Although I disagree with the premise (I think Python 3.2 is a fine platform to
> build many applications on)

Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact 
that people need more than “fine” to feel urged to switch to Python 3. I 
sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we 
might have a perfect storm. :)

> it's probably likely what we'll have backports of
> stable Python 3 releases to 12.04, at the very least in semi-official PPAs.

That's what I've been hoping for. Maybe it will work the other way around too: 
People like 3.3, target it first and port back later to reach more users. It's 
all about encouraging people to try the nectar of Python 3 – once they're 
caught it's sticky sweetness[1]… ;)

Cheers,
Hynek

[1] disclaimer: sticky sweetness only applies if you're not a maintainer of 
wsgi-related middleware/framework
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 414

[Hynek Schlawack]

Hi Ezio,

Am 02.03.2012 um 10:33 schrieb Ezio Melotti:

>> [quoting Armin from Reddit]
>> "Because in all honesty, because string wrappers make a codebase horrible to
>> work with. I will have to continue maintaining 2.x versions for at least 
>> another
>> four or five years. The idea if having to use string wrappers for that long
>> makes me puke."
> Reading this led me to think the following:
> * 2.5 is now available basically everywhere, and it was released almost 5 
> years ago (Sep 2006);
> * if it takes the same time for 3.3, it will be widespread after 4-5 years 
> (i.e. 2016-2017) [0];
> * if you want to target a Python 3 version that is widespread [1], you will 
> want to support 3.1/3.2 too in the meanwhile;
> * therefore you will have to use the hook on 3.1/3.2;
> * in 2016-2017 you'll finally be able to drop 3.1/3.2 and use only 3.3 
> without hooks;
> * in 2016-2017 you'll also stop maintaining the 2.x version (according to 
> that quote);
> * if you are not maintaining 2.x anymore, you won't need u'' -- right when 
> you could finally stop using the hook;

I don't think you can compare 2.5 and 3.2 like that. Although 3.2 is/will be 
shipped with some distributions, it never has, and never will have, the 
adoption of 2.5 that was "mainstream" for a quite long time.

3.3 is the IMHO the first 3.x release that brings really cool stuff to the 
table and might be the tipping point for people to start embracing Python 3 – 
despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I 
hope for some half-official back port there. :)


Re the language thingie (not directed towards Ezio): It's true that Armin tends 
to be opinionated – maybe even polemic. However I can't recall a case where he 
personally attacked people like it happened here.

Regards,
Hynek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 408 -- Standard library __preview__ package

[Hynek Schlawack]

Hi,

Am 27.01.2012 um 18:26 schrieb Alex:

> I'm -1 on this, for a pretty simple reason. Something goes into __preview__,
> instead of it's final destination directly because it needs feedback/possibly
> changes. However, given the release cycle of the stdlib (~18 months), any
> feedback it gets can't be seen by actual users until it's too late. 
> Essentially
> you can only get one round of stdlib.
> 
> I think a significantly healthier process (in terms of maximizing feedback and
> getting something into it's best shape) is to let a project evolve naturally 
> on
> PyPi and in the ecosystem, give feedback to it from an inclusion perspective,
> and then include it when it becomes ready on it's own merits. The counter
> argument to  this is that putting it in the stdlib gets you signficantly more
> eyeballs (and hopefully more feedback, therefore), my only response to this 
> is:
> if it doesn't get eyeballs on PyPi I don't think there's a great enough need 
> to
> justify it in the stdlib.

I agree with Alex on this: The iterations – even with PEP 407 – would be wayyy 
too long to be useful.

As for the only downside: How about endorsing certain pypi projects as possible 
future additions in order to give them more exposure? I'm sure there is some 
nice way for that.

Plus: Everybody could pin the version their code depends on right now, so 
updates wouldn't break anything. I.e. api users would have more peace of mind 
and api developers could develop more aggressively.

Bye,
-h
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python build failed on mac

[Hynek Schlawack]

Am Freitag, 20. Januar 2012 um 23:40 schrieb Vijay Majagaonkar:
> > > I am trying to build python 3 on mac and build failing with following 
> > > error can somebody help me with this
> > 
> > It is a known bug that Apple's latest gcc-llvm (that comes with Xcode 4.1 
> > by default as gcc) miscompiles Python: http://bugs.python.org/issue13241 
> > 
> > make clean
> > CC=clang ./configure && make -s
> 
> Thanks for the help, but above command need to run in different way
> 
> ./configure CC=clang
> make


I'm not sure why you think it "needs" to be that way, but it's fine by me as 
both ways work fine.

> this allowed me to build the code but when ran test I got following error 
> message
> 
> [363/364/3] test_io
> python.exe(11411) malloc: *** mmap(size=9223372036854775808) failed (error 
> code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> python.exe(11411,0x7fff7a8ba960) malloc: *** mmap(size=9223372036854775808) 
> failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> python.exe(11411,0x7fff7a8ba960) malloc: *** mmap(size=9223372036854775808) 
> failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> 
> I am using Mac OS-X 10.7.2 and insatlled Xcode 4.2.1 

Please ensure there aren't any gcc-created objects left by running "make 
distclean" first.

-h
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] python build failed on mac

[Hynek Schlawack]

Hello Vijay 


Am Freitag, 20. Januar 2012 um 00:56 schrieb Vijay N. Majagaonkar:

> I am trying to build python 3 on mac and build failing with following error 
> can somebody help me with this
It is a known bug that Apple's latest gcc-llvm (that comes with Xcode 4.1 by 
default as gcc) miscompiles Python: http://bugs.python.org/issue13241 

make clean
CC=clang ./configure && make -s

works though (despite the abundant warnings).

Regards,
-h

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of the fix for the hash collision ulnerability

[Hynek Schlawack]

Am Sonntag, 15. Januar 2012 um 05:49 schrieb Steven D'Aprano:
> > I don't think anyone doubts that this will break lots of code (at least,
> > the arguments I've heard have been "their code is broken", not "nobody does
> > that").
> 
> I don't know about "lots" of code, but it will break at least one library (or 
> so I'm told):
> 
> http://mail.python.org/pipermail/python-list/2012-January/1286535.html
Sadly, suds is also Python's _only_ usable SOAP library at this moment. :( (on 
top of that, the development is in limbo ATM)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: Issue #9993: When the source and destination are on different filesystems,

[Hynek Schlawack]

Hi Nick,  


Am Samstag, 7. Januar 2012 um 14:22 schrieb Nick Coghlan:

> > http://hg.python.org/cpython/rev/1ea8b7233fd7
> > changeset: 74288:1ea8b7233fd7
> > user: Antoine Pitrou mailto:solip...@pitrou.net)>
> > date: Fri Jan 06 20:16:19 2012 +0100
> > summary:
> > Issue #9993: When the source and destination are on different filesystems,
> > and the source is a symlink, shutil.move() now recreates a symlink on the
> > destination instead of copying the file contents.
> > Patch by Jonathan Niehof and Hynek Schlawack.
>  
> That seems like a fairly nasty backwards incompatibilty right there.
> While the old behaviour was different from mv, it was still perfectly
> well defined. Now, operations that used to work may fail - basically
> anything involving an absolute symlink will silently fail if being
> moved to removable media (it will create a symlink that is completely
> useless on the destination machine). Relative symlinks may or may not
> be broken depending on whether or not their target is *also* being
> copied to the destination media.

I had a look at it, the possible cases are as following:

1. we can just do a os.rename(): if src is a link it stays one
2. os.rename() fails, src is not a symlink but a directory: copytree() is used 
with symlinks=True, i.e. symlinks are preserved, no matter where they point to, 
i.e. this would clash with removable media as well.
3. os.rename() fails and src is a symlink. In both former cases, links were 
preserved. And the removable-media-argument is IMHO moot due to case 2.

If you want hardcore backwards compatibility, we could make the old behavior 
default and add some flag. But to be honest, the new approach seems more 
congruent to me.  
> The new help text also doesn't say what will happen if the destination
> doesn't even *support* symlinks (as is quite likely in the removable
> media case).

A clarification might be appropriate. Maybe even a direct warning, that in such 
cases the usage of copytree(…, symlinks=False) might be a better idea?

But the more I think about it, the more it's my impression, that symlink 
problems aren't really our problems as they go through all possible layers and 
it's next to impossible to catch all edge cases in library code. Therefore I'd 
say it's best just to behave like UNIX tools (please note I'm not defensive 
here, I've just fixed the tests+docs :)).

Cheers,
Hynek

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hash collision security issue (now public)

[Hynek Schlawack]

Hi,  

how about

Option d: Host based salt
 + Easy-ish to implement – how about basing it on the hostname for example?
 + transparent for all processes on the same host
 - probably unit test breakage

In fact, we could use host based as default with the option to specify own 
which would solve the sync problems.

That said, I agree with Armin that fixing this in the frameworks isn't an 
option.

Regards,
Hynek


Am Donnerstag, 29. Dezember 2011 um 13:57 schrieb Armin Ronacher:

> Hi,
>  
> Something I should add to this now that I thought about it a bit more:
>  
> Assuming this should be fixed on a language level the solution would
> probably be to salt hashes. The most common hash to salt here is the
> PyUnicode hash for obvious reasons.
>  
> - Option a: Compiled in Salt
> + Easy to implement
> - Breaks unittests most likely (those were broken in the first place
> but that's still a very annoying change to make)
> - Might cause problems with interoperability of Pythons compiled with
> different hash salts
> - You're not really solving the problem because each linux
> distribution (besides Gentoo I guess) would have just one salt
> compiled in and that would be popular enough to have the same
> issue.
>  
> - Option b: Environment variable for the salt
> + Easy-ish to implement
> + Easy to synchronize over different machines
> - initialization for base types happens early and unpredictive which
> makes it hard for embedded Python interpreters (think mod_wsgi and
> other things) to specify the salt
>  
> - Option c: Random salt at runtime
> + Easy to implement
> - impossible to synchronize
> - breaks unittests in the same way as a compiled in salt would do
>  
> Where to add the salt to? Unicode strings and bytestrings (byte
> objects) I guess since those are the most common offenders. Sometimes
> tuples are keys of dictionaries but in that case a contributing factor
> to the hash is the string in the tuple anyways.
>  
> Also related: since this is a security related issue, would this be
> something that goes into Python 2? Does that affect how a fix would
> look like?
>  
>  
> Regards,
> Armin
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/hs%40ox.cx



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com