Re: [Python-Dev] PEP 427: data directory
On 22 October 2012 21:35, Daniel Holth wrote:
> On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>>>
>>> Hello,
>>>
>>> The FAQ has this weird statement:
>>>
>>> “This specification does not have an opinion on how you should organize
>>> your code. The .data directory is just a place for any files that are
>>> not normally installed inside site-packages or on the PYTHONPATH.”
>
> I mean to say that just because there is a .data/ directory it doesn't
> mean you have to stop using pkgutil.get_data(package, resource). Some
> people will take those 4 letters "data" to mean that any file that
> doesn't start with .py has to go there instead of in the root of the
> archive.
It might be worth being very explicit in the PEP that the wheel format
is based specifically on the distutils/sysconfig categories for file
locations (purelib, platlib, data, scripts, ...). If a setup.py is
written with custom code to install scripts in locations not
controlled by the various --install-XXX flags to distutils, it is
undefined how to package the non-standard files in the wheel format.
This is the same behaviour as for the wininst format (certainly, I've
checked the code :-)) and the egg format (I think, but I didn't check
the code for this).
Antoine's example of /etc/init.d is *not* custom code, it is standard
distutils (although not very well documented :-() What setup.py
install does is to make the given path relative to the data directory
which is sys.prefix on Windows, and appears to be similar on Posix
(the value of sysconfig.get_path('data') should give it, but I don't
have a Linux box handy to try it on). I don't see any obvious
documentation confirming that it does what I assume Antoine actually
wants, which is to put the file in /etc/init.d (which would of course
make the package non-relocatable, and hence mean that it would break
isolation in a virtualenv).
Apologies if this is obvious to everyone, but I suspect it should be
stated explicitly in the PEP, if only to avoid confusion. Something
like the following:
"""
The contents of a wheel file consist of:
1. The root of the wheel, which is all files to be installed in
"purelib" (or "platlib" if there is no purelib)
2. The dist-info directory, containing metadata
3. The data directory, which contains one subdirectory for each
sysconfig scheme not already covered (i.e., data, scripts, include,
and possibly platlib)
How files which would be installed to locations not defined by a
sysconfig path are stored in a wheel is not defined by this version of
the spec.
This layout offers all of the functionality of the existing wininst
and egg binary formats.
"""
Paul
___
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 427 comment: code signing
On Tue, Oct 23, 2012 at 7:46 AM, wrote:
> That's exactly what I want: it (PEP 427) should use one of the algorithms
> that is built-in (into web signatures). Web signatures give a choice of
> three algorithms; yet Daniel proposes to deviate and use a non-builtin
> algorithm.
>
> None of the algorithms in question are built in in Python; the two
> standard algorithms with public keys (i.e. RSA and ECDSA) are both
> built into OpenSSL.
What leads you to say that? ISTM Python has perfectly good support for
JWS/JWA's HS256 algorithm. In fact, here's an implementation that I
think would conform to the current JWS draft:
def sign(payload, key):
h = json.dumps({'alg': 'HS256'})
input = b64uencode(h) + '.' + b64uencode(json.dumps(payload))
sig = hmac.new(key, input, hashlib.sha256).digest()
return input + '.' + b64uencode(sig)
(b64u implementations elided; see
https://bitbucket.org/djc/persona-totp for the rest of the code.)
Cheers,
Dirkjan
___
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] Split unicodeobject.c into subfiles
2012/10/22 Victor Stinner : > Hi, > > I forked CPython repository to work on my "split unicodeobject.c" project: > http://hg.python.org/sandbox/split-unicodeobject.c > > The result is 10 files (included the existing unicodeobject.c): > > 1176 Objects/unicodecharmap.c > 1678 Objects/unicodecodecs.c > 1362 Objects/unicodeformat.c >253 Objects/unicodeimpl.h >733 Objects/unicodelegacy.c > 1836 Objects/unicodenew.c > 2777 Objects/unicodeobject.c > 2421 Objects/unicodeoperators.c > 1235 Objects/unicodeoscodecs.c > 1288 Objects/unicodeutfcodecs.c > 14759 total > > This is just a proposition (and work in progress). Everything can be changed > :-) > > "unicodenew.c" is not a good name. Content of this file may be moved > somewhere else. > > Some files may be merged again if the separation is not justified. > > I don't like the "unicode" prefix for filenames, I would prefer a new > directory. > > -- > > Shorter files are easier to review and maintain. The compilation is > faster if only one file is modified. > > The MBCS codec requires windows.h. The whole unicodeobject.c includes > it just for this codec. With the split, only unicodeoscodecs.c > includes this file. > > The MBCS codec needs also a "winver" variable. This variable is > defined between the BLOOM filter and the unicode_result_unchanged() > function. How can you explain how these things are sorted? Where > should I add a new function or variable? With the split, the variable > is now defined very close to where is it used. You don't have to > scroll 7000 lines to see where it is used. > > If you would like to work on a specific function, you don't have to > use the search function of your editor to skip thousands to lines. For > example, the 18 functions and 2 types related to the charmap codec are > now grouped into one unique and short C file. > > It was already possible to extend and maintain unicodeobject.c (some > people proved it!), but it should now be much simpler with shorter > files. I would like to repeat my opposition to splitting unicodeobject.c. I don't think the benefits of such a split have been well justified, certainly not to the point that the claim about "much simpler" maintenance is true. -- Regards, Benjamin ___ 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] Split unicodeobject.c into subfiles
On 23.10.2012 10:22, Benjamin Peterson wrote: > 2012/10/22 Victor Stinner : >> Hi, >> >> I forked CPython repository to work on my "split unicodeobject.c" project: >> http://hg.python.org/sandbox/split-unicodeobject.c >> >> The result is 10 files (included the existing unicodeobject.c): >> >> 1176 Objects/unicodecharmap.c >> 1678 Objects/unicodecodecs.c >> 1362 Objects/unicodeformat.c >>253 Objects/unicodeimpl.h >>733 Objects/unicodelegacy.c >> 1836 Objects/unicodenew.c >> 2777 Objects/unicodeobject.c >> 2421 Objects/unicodeoperators.c >> 1235 Objects/unicodeoscodecs.c >> 1288 Objects/unicodeutfcodecs.c >> 14759 total >> >> This is just a proposition (and work in progress). Everything can be changed >> :-) >> >> "unicodenew.c" is not a good name. Content of this file may be moved >> somewhere else. >> >> Some files may be merged again if the separation is not justified. >> >> I don't like the "unicode" prefix for filenames, I would prefer a new >> directory. >> >> -- >> >> Shorter files are easier to review and maintain. The compilation is >> faster if only one file is modified. >> >> The MBCS codec requires windows.h. The whole unicodeobject.c includes >> it just for this codec. With the split, only unicodeoscodecs.c >> includes this file. >> >> The MBCS codec needs also a "winver" variable. This variable is >> defined between the BLOOM filter and the unicode_result_unchanged() >> function. How can you explain how these things are sorted? Where >> should I add a new function or variable? With the split, the variable >> is now defined very close to where is it used. You don't have to >> scroll 7000 lines to see where it is used. >> >> If you would like to work on a specific function, you don't have to >> use the search function of your editor to skip thousands to lines. For >> example, the 18 functions and 2 types related to the charmap codec are >> now grouped into one unique and short C file. >> >> It was already possible to extend and maintain unicodeobject.c (some >> people proved it!), but it should now be much simpler with shorter >> files. > > I would like to repeat my opposition to splitting unicodeobject.c. I > don't think the benefits of such a split have been well justified, > certainly not to the point that the claim about "much simpler" > maintenance is true. Same feelings here. If you do go ahead with such a split, please only split the source files and keep the unicodeobject.c file which then includes all the other files. Such a restructuring should not result in compilers no longer being able to optimize code by inlining functions in one of the most important basic types we have in Python 3. Also note that splitting the file in multiple smaller ones will actually create more maintenance overhead, since patches will likely no longer be easy to merge from 3.3 to 3.4. BTW: The positive effect of having everything in one file is that you no longer have to figure which files to look when trying to find a piece of logic... it's just a ctrl-f or ctrl-s away :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 23 2012) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2012-09-27: Released eGenix PyRun 1.1.0 ... http://egenix.com/go35 2012-09-26: Released mxODBC.Connect 2.0.1 ... http://egenix.com/go34 2012-09-25: Released mxODBC 3.2.1 ... http://egenix.com/go33 2012-10-23: Python Meeting Duesseldorf ... today eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Split unicodeobject.c into subfiles
> Such a restructuring should not result in compilers > no longer being able to optimize code by inlining functions > in one of the most important basic types we have in Python 3. I agree that performances are important. But I'm not convinced than moving functions has a real impact on performances, not that such issues cannot be fixed. I tried to limit changes impacting performances. Inlining is (only?) interesting for short functions. PEP 393 introduces many macros for this. I also added some "Fast" functiions (_PyUnicode_FastCopyCharacters() and _PyUnicode_FastFill()) which don't check parameters and do the real work. I don't think that it's really useful to inline _PyUnicode_FastFill() in the caller for example. I will check performances of all str methods. For example, str.count() is now calling PyUnicode_Count() instead of the static count(). PyUnicode_Count() adds some extra checks, some of them are not necessary, and it's not a static function, so it cannot(?) be inlined. But I bet that the overhead is really low. Note: Since GCC 4.5, Link Time Optimization are possible. I don't know if GCC is able to inline functions defined in different files, but C compilers are better at each release. -- I will check the impact of performances on _PyUnicode_Widen() and _PyUnicode_Putchar(), which are no more static. _PyUnicode_Widen() and _PyUnicode_Putchar() are used in Unicode codecs when it's more expensive to compute the exact length and maximum character of the output string. These functions are optimistic (hope that the output will not grow too much and the string is not "widen" too much times, so it should be faster for ASCII). I implemented a similar approach in my PyUnicodeWriter API, and I plan to reuse this API to simplify the API. PyUnicodeWriter uses some macro to limit the overhead of having to check before each write if we need to enlarge or widen the internal buffer, and allow to write directly into the buffer using low level functions like PyUnicode_WRITE. I also hope a performance improvement because the PyUnicodeWriter API can also overallocate the internal buffer to reduce the number of calls to realloc() (which is usually slow). > Also note that splitting the file in multiple smaller ones will > actually create more maintenance overhead, since patches will > likely no longer be easy to merge from 3.3 to 3.4. I'm a candidate to maintain unicodeobject.c. In your check unicodeobject.c (recent) history, I'm one of the most active developer on this file since two years (especially in 2012). I'm not sure that merges on this file are so hard. Victor ___ 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] Split unicodeobject.c into subfiles
Le 23/10/2012 12:05, Victor Stinner a écrit : Such a restructuring should not result in compilers no longer being able to optimize code by inlining functions in one of the most important basic types we have in Python 3. I agree that performances are important. But I'm not convinced than moving functions has a real impact on performances, not that such issues cannot be fixed. I agree with Marc-André, there's no point in compiling those files separately. #include'ing them in the master unicodeobject.c file is fine. Regards Antoine. ___ 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 427 comment: code signing
On Tue, Oct 23, 2012 at 1:42 AM, wrote: > I'm also -1 on the notion that the entire key distribution matter is out > of scope. With that approach, I feel that the package signing is essentially > pointless. > > As a general note on this, this entire issue lacks a threat model: > what kind of attack do you want to protect against? I can't think of > any realistic threat that is effectively protected against with your > signature scheme. It is designed to protect against a man-in-the-middle attack. What if I'm at pycon using an open access point? An attacker has proxied the connection to provide malware instead of the correct packages. Thankfully, the tahoe-lafs developers have sent me a PGP-signed requirements file with the keys of all the dependencies they trust: allmydata-tahoe[algorithmkey=YDWz8J6HAQc1V4_EoO-1cEGHSHjRd-5HYjj4hPCmSVZUZDm67-NngM2_XcMJOddXBv6xNLjK91DEn20KZCSFeBdMzeohE1YNq__4CT91StT0cQ_zhrQ1vwwwILZuOfgPmVep3lw2Jn3KVnl1PBw7P1WjuCctENxwuFz3NuWhER_uldA-0ted0SYKvvD5zI85epp8mRucxw0d7NUTdtTci7Hyx-ujTBDlTIB-tEIQ_9eJf9BznFuqvvfYf4qlfgjF4nvDgU1pQfbu6RSBOVdZEFgNqoPWV-Qo_4HjyKA7WG0Xk9OI92Jl3JkZRV2bP-KdRwbnUj7dyVSvhr2ilWx0s380epSSPLBByrmW8dkj_b8NJwSVk5J6rWMqKplINZlpWW5j3O1pn2U5e-XG6AWBNZd5r89MhXHhz2PA9CyGb7sINRljC716tdz-RYaFD2lScdszygNsMBvLHcyz9GQmjPtK4GhQQGrRyu40Q3BWJWq4l70pBBmG] Twisted[algorithmkey=YDWz8J6HAQc1V4_EoO-1cEGHSHjRd-5HYjj4hPCmSVZUZDm67-NngM2_XcMJOddXBv6xNLjK91DEn20KZCSFeBdMzeohE1YNq__4CT91StT0cQ_zhrQ1vwwwILZuOfgPmVep3lw2Jn3KVnl1PBw7P1WjuCctENxwuFz3NuWhER_uldA-0ted0SYKvvD5zI85epp8mRucxw0d7NUTdtTci7Hyx-ujTBDlTIB-tEIQ_9eJf9BznFuqvvfYf4qlfgjF4nvDgU1pQfbu6RSBOVdZEFgNqoPWV-Qo_4HjyKA7WG0Xk9OI92Jl3JkZRV2bP-KdRwbnUj7dyVSvhr2ilWx0s380epSSPLBByrmW8dkj_b8NJwSVk5J6rWMqKplINZlpWW5j3O1pn2U5e-XG6AWBNZd5r89MhXHhz2PA9CyGb7sINRljC716tdz-RYaFD2lScdszygNsMBvLHcyz9GQmjPtK4GhQQGrRyu40Q3BWJWq4l70pBBmG] ... and so on. I pip install --signed-only -r tahoe-requirements.txt (not implemented yet) to install the application, knowing the packages come from the publishers the app developer expected. ___ 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] Split unicodeobject.c into subfiles
2012/10/23 Antoine Pitrou : > I agree with Marc-André, there's no point in compiling those files > separately. #include'ing them in the master unicodeobject.c file is fine. I also find the unicodeobject.c difficult to navigate. Even if we don't split the file, I'd advocate a better presentation of its content. Could we have at least clear sections, with titles and descriptions? And use the ^L page separator for Emacs users? Code in posixmodule.c could also benefit of a better layout. -- Amaury Forgeot d'Arc ___ 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 427: data directory
On Tue, Oct 23, 2012 at 3:04 AM, Paul Moore wrote:
> On 22 October 2012 21:35, Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote:
>>> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
Hello,
The FAQ has this weird statement:
“This specification does not have an opinion on how you should organize
your code. The .data directory is just a place for any files that are
not normally installed inside site-packages or on the PYTHONPATH.”
>>
>> I mean to say that just because there is a .data/ directory it doesn't
>> mean you have to stop using pkgutil.get_data(package, resource). Some
>> people will take those 4 letters "data" to mean that any file that
>> doesn't start with .py has to go there instead of in the root of the
>> archive.
>
> It might be worth being very explicit in the PEP that the wheel format
> is based specifically on the distutils/sysconfig categories for file
> locations (purelib, platlib, data, scripts, ...). If a setup.py is
> written with custom code to install scripts in locations not
> controlled by the various --install-XXX flags to distutils, it is
> undefined how to package the non-standard files in the wheel format.
> This is the same behaviour as for the wininst format (certainly, I've
> checked the code :-)) and the egg format (I think, but I didn't check
> the code for this).
>
> Antoine's example of /etc/init.d is *not* custom code, it is standard
> distutils (although not very well documented :-() What setup.py
> install does is to make the given path relative to the data directory
> which is sys.prefix on Windows, and appears to be similar on Posix
> (the value of sysconfig.get_path('data') should give it, but I don't
> have a Linux box handy to try it on). I don't see any obvious
> documentation confirming that it does what I assume Antoine actually
> wants, which is to put the file in /etc/init.d (which would of course
> make the package non-relocatable, and hence mean that it would break
> isolation in a virtualenv).
>
> Apologies if this is obvious to everyone, but I suspect it should be
> stated explicitly in the PEP, if only to avoid confusion. Something
> like the following:
>
> """
> The contents of a wheel file consist of:
>
> 1. The root of the wheel, which is all files to be installed in
> "purelib" (or "platlib" if there is no purelib)
> 2. The dist-info directory, containing metadata
> 3. The data directory, which contains one subdirectory for each
> sysconfig scheme not already covered (i.e., data, scripts, include,
> and possibly platlib)
>
> How files which would be installed to locations not defined by a
> sysconfig path are stored in a wheel is not defined by this version of
> the spec.
>
> This layout offers all of the functionality of the existing wininst
> and egg binary formats.
> """
Thanks, this part of the PEP needs clarification. Note the PEP is
currently using the distutils.command.install schemes instead of
sysconfig in order to get the 'headers' key.
Is anyone reading this actually using the purelib != platlib feature?
___
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] Split unicodeobject.c into subfiles
On 10/23/2012 10:22 AM, Benjamin Peterson wrote: > 2012/10/22 Victor Stinner : >> Hi, >> >> I forked CPython repository to work on my "split unicodeobject.c" project: >> http://hg.python.org/sandbox/split-unicodeobject.c >> >> The result is 10 files (included the existing unicodeobject.c): >> >> 1176 Objects/unicodecharmap.c >> 1678 Objects/unicodecodecs.c >> 1362 Objects/unicodeformat.c >>253 Objects/unicodeimpl.h >>733 Objects/unicodelegacy.c >> 1836 Objects/unicodenew.c >> 2777 Objects/unicodeobject.c >> 2421 Objects/unicodeoperators.c >> 1235 Objects/unicodeoscodecs.c >> 1288 Objects/unicodeutfcodecs.c >> 14759 total >> >> This is just a proposition (and work in progress). Everything can be changed >> :-) >> >> "unicodenew.c" is not a good name. Content of this file may be moved >> somewhere else. >> >> Some files may be merged again if the separation is not justified. >> >> I don't like the "unicode" prefix for filenames, I would prefer a new >> directory. >> >> -- >> >> Shorter files are easier to review and maintain. The compilation is >> faster if only one file is modified. >> >> The MBCS codec requires windows.h. The whole unicodeobject.c includes >> it just for this codec. With the split, only unicodeoscodecs.c >> includes this file. >> >> The MBCS codec needs also a "winver" variable. This variable is >> defined between the BLOOM filter and the unicode_result_unchanged() >> function. How can you explain how these things are sorted? Where >> should I add a new function or variable? With the split, the variable >> is now defined very close to where is it used. You don't have to >> scroll 7000 lines to see where it is used. >> >> If you would like to work on a specific function, you don't have to >> use the search function of your editor to skip thousands to lines. For >> example, the 18 functions and 2 types related to the charmap codec are >> now grouped into one unique and short C file. >> >> It was already possible to extend and maintain unicodeobject.c (some >> people proved it!), but it should now be much simpler with shorter >> files. > > I would like to repeat my opposition to splitting unicodeobject.c. I > don't think the benefits of such a split have been well justified, > certainly not to the point that the claim about "much simpler" > maintenance is true. I agree. I haven't edited much in unicodeobject.c lately, so this is just an expression of my preference in general to keep things together. We tell new Python programmers to stop worrying about using indentation for grouping because editors are meant to make this easy. A similar argument applies to navigating large files: with a decent editor there is no real problem with large files. I agree completely with suggestions to improve sectioning and/or comments within the file. But once you make any split, people will look for things in the wrong file. It happens for me every time I look for something in either object.c or abstract.c -- that's an instance where the function name prefix doesn't imply the implementation file name, which is otherwise very clear and easy in the Python sources. Especially since you're suggesting a huge number of new files, I question the argument of better navigability. Georg BTW: > If you would like to work on a specific function, you don't have to > use the search function of your editor to skip thousands to lines. For > example, the 18 functions and 2 types related to the charmap codec are > now grouped into one unique and short C file. After opening the right file, I *still* use the search function to get to the function I want to edit. Don't tell me using a scroll bar to scan for the right place is faster... ___ 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 Bug Day in October
Hello, Le 12/10/2012 13:50, Petri Lehtinen a écrit : > It's two and a half weeks left, but I've not seen any announcements > yet! Indeed, work and other commitments took over, so we (Montréal-Python) decided to move the bug day instead of announcing it late. The date that would work for us is November 3rd. Brian, is it okay for Boston? Maciej, what about your group? Comitters, who could join on IRC? Sorry for the false start. Best regards ___ 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 Bug Day in October
On Tue, 23 Oct 2012 21:19:29 -0400, wrote: > Le 12/10/2012 13:50, Petri Lehtinen a écrit : > > It's two and a half weeks left, but I've not seen any announcements > > yet! > Indeed, work and other commitments took over, so we (Montréal-Python) > decided to move the bug day instead of announcing it late. The date > that would work for us is November 3rd. > > Brian, is it okay for Boston? > Maciej, what about your group? > Comitters, who could join on IRC? > > Sorry for the false start. This is very disappointing. You had previously said that it was a go. People (who may or may not have spoken up here) may have already arranged space and be planning on it, despite the lack of announcement. I certainly was planning on it. I'm not available on the 3rd. I'll continue with my plans to be active in the IRC channel and focused on Python bug fixing this Saturday from some time in the AM until about 18:00, GMT -4. If no one else shows up I'll just have a personal bug day, but I'm guessing at least a few people might show up despite the lack of a wider formal announcement. --David ___ 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 Bug Day in October
Le 23/10/2012 21:52, R. David Murray a écrit : > This is very disappointing. You had previously said that it was a go. > People (who may or may not have spoken up here) may have already > arranged space and be planning on it, despite the lack of announcement. > I certainly was planning on it. Okay, I was assuming silence meant the user groups had made no definite arrangements. The decision of not having a physical sprint in Montreal doesn't have to affect the whole day, so I will be connected from home, and the other people who wanted to participate can join in. To make it clear: Bug day on IRC this Saturday is still on. I'm updating the old wiki page to point to the new devguide and Petri's bug list. - http://docs.python.org/devguide/ - http://piratepad.net/pyconfi-sprint-issues Sorry for the confusion. ___ 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 Bug Day in October
On Tue, Oct 23, 2012 at 8:19 PM, Éric Araujo wrote: > Hello, > > Le 12/10/2012 13:50, Petri Lehtinen a écrit : >> It's two and a half weeks left, but I've not seen any announcements >> yet! > Indeed, work and other commitments took over, so we (Montréal-Python) > decided to move the bug day instead of announcing it late. The date > that would work for us is November 3rd. > > Brian, is it okay for Boston? > Maciej, what about your group? > Comitters, who could join on IRC? > > Sorry for the false start. Nothing was formally planned to happen in Chicago due to the usual lack of interest, and I doubt that'll change for November 3rd. I would suggest just going on with whatever sprint date(s) your group is able to make it for. This is already very loosely organized as it is, so trying to coordinate multiple groups in multiple cities is not worth it. Anyway, I'll probably be around this Saturday and November 3rd to put in some work. ___ 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
