Re: Code correctness, and testing strategies
In article <[EMAIL PROTECTED]>, David <[EMAIL PROTECTED]> wrote: >> Clients generally require *working* software. Unfortunately it is all too >> easy to ship something broken because then you can claim you completed the >> coding on time and any slippage gets lost in the next 5 years of >> maintenance. > >That's why you have human testing & QA. Unit tests can help, but they >are a poor substitute. If the customer is happy with the first >version, you can improve it, fix bugs, and add more unit tests later. The most important aspect of usnit testing is actually that it makes the code testable. This may sound lik an oxymoron but it is actually a really important property. Testable code has to have a level of modularity as well as simplicity and clarity in its interfaces that you will not achieve in code that lacks automated unit tests. You can easily convince yourself that this is true by adding complete coverage unit tests to some code after you have written it. It's tough work and more often than not, you need to refactor the code to make it testable. Another aspect that you are raising is the use of human testing and QA. I agree that these are important, but every bug they discover is a failure of the developers and their tests. Our testers can sail through a testbed in 30 minutes if there are no bugs. Every single bug adds 30-60 minutes of testers time in order to pinpoint the bug and supply the developers with enough information to locate and fix it. Add some 10 minutes to testing time on the next testbed to verify that the bug is actually fixed. In my end of the world, tester time is not cheaper than developer time. It is also a scarcer resource than developer time. The roundtrips between developers and testers also add to real required to develop the product. There will always be delays introduced by having to produce the tester with a testable system, wait for the tests to happen, have the report written up and allocated to a developer etc. With TDD most of these bugs will be caught in a no-delay loop at the developers desk. This last fact has another important property that is easily overlooked. Once the off-by-one errors and other trivial bugs don't clutter the minds of the testers they will start thinking more clearly about the application and where the really nasty bugs are found - the ones where your thinking went wrong but your implementation is correct. if the testers are busy tracking trivial bugs, your customers will find the nasty one. If you are lucky, they will tell you. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Code correctness, and testing strategies
In article <[EMAIL PROTECTED]>, David <[EMAIL PROTECTED]> wrote: >> I work in small increments, writing one test at a time, then some code, >> then another test, then some more code, etc. In fact, I take this to what >> many people might call an extreme. > >Thanks for the replies. > >I've read about the TDD (and similar) approaches. Maybe I need to try >it and get used to it, but there are a few things I don't like about >it on a gut level. I'll try to enumerate my concerns here. > >Problem 1: You can only code against tests > >Basically, with TDD you write the tests first, then the code which >passes/fails the tests as appropriate. However, as you're writing the >code you will also think of a lot of corner cases you should also >handle. The natural way to do this is to add them to the code first. >But with TDD you have to first write a test for the corner case, even >if setting up test code for it is very complicated. So, you have these >options: > >- Take as much time as needed to put a complicated test case in place. >- Don't add corner case to your code because you can't (don't have >time to) write a test for it. >- Add the corner case handling to the code first, and try to add a >test later if you have time for it. As you come up with the corner case, write a test for it and leave the implementation for later. The hard part of coding is always defining your problem. Once it is defined (by a test) the solution is just a matter of tidy work. >Problem 2: Slows down prototyping > >In order to get a new system working, it's nice to be able to throw >together a set of modules quickly, and if that doesn't work, scrap it >and try something else. There's a rule (forget where) that your first >system will always be a prototype, regardless of intent. > >With TDD, you have to first write the tests for the first version. >Then when that first version doesn't work out, you end up scrapping >the tests and the code. The time spent writing the tests was wasted. > Agreed. There is no good way of reusing your prototype code in TDD. You end up having to throw your propotype away in order to have a proper tested implementation in the end. Takes more time up front, but less time over the lifecycle of the program you are building. >Problem 3: Slows down development in general > >Having to write tests for all code takes time. Instead of eg: 10 hours >coding and say 1/2 an hour manual testing, you spend eg: 2-3 hours >writing all the tests, and 10 on the code. This is incorrect. It speeds up development in general. The debugging phase of development becomes much shorter because the bugs are fewer and the ones you have a much shallower. There are so many tests that reduce the scope in which you have to search for the bug that it usually becomes trivial to find. I have direct experience from this, getting my company to change to TDD about 10 months ago. Productivity has improved enormously. I'd say that we have cut between 25 and 50% in development time. >Problem 4: Can make refactoring difficult. > >If you have very complete & detailed tests for your project, but one >day you need to change the logic fundamentally (maybe change it from >single-threaded to multi-threaded, or from running on 1 server to >distributed), then you need to do a large amount of test refactoring >also. The more tests you have (usually a good thing), the longer it >will take to update all the tests, write new ones, etc. It's worse if >you have to do all this first before you can start updating the code. No, this is a total misunderstanding. It makes refactoring much easier. It takes a bit of time to refactor the affected tests for the module, but you gain so much by having tests that show that your refactoring is not breaking code that should be unaffected that it saves the extra time spent many times over. Introducing bugs because you missed some aspect in a refactoring is one of the most common problems in non-TDD code and it is a really nasty quality concern. > >Problem 5: Tests are more important than code > >You need to justify the extra time spent on writing test code. Tests >are nice, and good to have for code maintainability, but they aren't >an essential feature (unless you're writing critical software for life >support, etc). Clients, deadlines, etc require actual software, not >tests for software (that couldn't be completed on time because you >spent too much time writing tests first ;-)). > The tests are as important as the code. As a customer, I don't think I'd buy software today unless I know that it has been built using TDD. Certainly I am ahead of the curve in this, but it won't be long before this will be required by skilled organisations buying software and sooner or later the rest of the world will follow. Getting into a TDD mindset is hard work, but those who succeed produce better software with less effort. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Psyco alternative
In article <[EMAIL PROTECTED]>, sturlamolden <[EMAIL PROTECTED]> wrote: >On Mar 27, 4:44 pm, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > >> PyPy is self-hosted and has been for some time (a year or so?). > >This is technically not correct. PyPy is hosted by RPython, which is >not Python but a different language all together. This is pure FUD! PyPy is written in RPython, which is a pure subset of Python, designed for writing interpreters in such a way that they can be translated into source code for a static language and then compiled to machine code. The translation toolchain, written in Python is used to create a binary image, which is a full interpreter for the Python language. This binary image can run the toolchain to generate another, identical binary image, which of course also is a a full interpreter for the Python language. This makes PyPy self hosting in every sense of the word. The fact that the interpreter is written in RPython and actually runs as an interpreted program under CPyton or a compiled PyPy is a useful implementation detail, adding yet another aspect of self hosting that is not present in other systems that claim to be self hosting. PyPy btw, is alive and well. Work is progressing along 3 major fronts. One is supporting real world applications, where we recently added support for ctypes and where we are working on ensuring that a number of popular modules and frameworks run under PyPy. Another major undertaking has been to improve execution speed without the JIT. We can report that we are faster than CPython on some benchmarks, while slower on others. On the average, I'd say that we still have some catching up to do. The third avenue that is being pursued is the JIT. While a huge refactoring has been finished and the results look very good, there are still many months of work to do before the JIT can be used in production. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python too complex ?!?!?!
In article <[EMAIL PROTECTED]>, Chris Mellon <[EMAIL PROTECTED]> wrote: >On Nov 22, 2007 3:04 PM, Brian <[EMAIL PROTECTED]> wrote: > >> / Chime Mode >> I have, in fact, sent this thread to my friend. >> His limiting factors are >> >> - money-control people favor MS platforms >> - C# and VS have minimal cost impact for academia >> - sys admins have everything locked down (probably >> essential for high school and community college) >> - both Python 2.4.2, then 2.5.1, on XP and Win2k >> crashed approx 10% of lab cptrs, so lab techs refused >> to allow further install of any 'third-party' s/w. >> (side note - I have installed Python and all the >> supporting stuff for PyVISA on 14 work-site (11 XP, 3 >> Debian) cptrs with no problem, so I do not understand). >> - no such thing as TAs in JC or HS. >> - CS instructors, for the effected schools, are not >> allowed to config machines or admin the network. >> - money-control people want students to learn skills >> that are on the IT buzz-word list. >> - my friend is no longer allowed to use me as an >> 'unofficial' assistant in these classes (not considered >> qualified because I only have a B.S. degree), so he >> only uses stuff that existing staff are (supposedly) >> familiar with... >> / Chime Mode >> >> I told my friend, the wannabe Python instructor, to >> walk away from any more volunteer work, and stick to >> the paid stuff. American education, what a mess... >> > > >Pretty unfortunate stuff, especially that he doesn't have any >permission to configure the machines for his course. These are all >(mostly?) political problems in his specific situation, though, not >issues with Python per se - except in the general sense that Python >doesn't get much respect. > >Except possibly the crashes, although honestly public school computer >labs tend to be incredibly hostile environments (admin lockdowns >notwithstanding). > >Support for even mildly off the beaten track thinking is in short >supply in most schools, I'm sad to hear of your friends problems. When you install Microsoft software,like C#/.NET,and it fails, this is percieved as your problem. You did not have the skills required to do the job. When you fail to install third party software, like Python, this is percieved to be a problem with the software package. The people building it did not have the skills required to do the job properly. Microsoft has this teflon effect. Never their fault that things do not work as expected. Jacob -- -- http://mail.python.org/mailman/listinfo/python-list
Re: ten small Python programs
In article <[EMAIL PROTECTED]>, Steve Howell <[EMAIL PROTECTED]> wrote: >I've always thought that the best way to introduce new >programmers to Python is to show them small code >examples. Something like this: http://www.lava.se/sam/ Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: PyPy 1.0: JIT compilers for free and more
In article <[EMAIL PROTECTED]>, Jarek Zgoda <[EMAIL PROTECTED]> wrote: >Carl Friedrich Bolz napisa³(a): > >> Welcome to the PyPy 1.0 release - a milestone integrating the results >> of four years of research, engineering, management and sprinting >> efforts, concluding the 28 months phase of EU co-funding! > >So it took 4 yars of work and over 2 yaers of consumption of EU funds, >yeah, great. > >Could anybody explain, what this gives to Python and its users? Would >we, eventually, get GIL-free VM, that is capable to consume all >available power of multicore processors? Or, maybe, we'll get something >special, I am unable to dream of? Or is it purely academic project to >create Python VM in Python? No, PyPy is not a purely academic project. It has been a practically oriented project from the very start. For the regular user of Python, the main benefit of PyPy is execution speed. With the Just-in-time optimizer, we have examples of functions doing integer math that are 63 times faster than CPython. Further work will broaden the scope of the optimizations to other language constructs. Bulding the framework for the JIT took a long time. Now that it is in place, extending the range of optimizations is a much smaller task. For the Python language developers, PyPy offers an easy environment for testing new ideas. Changes and alternative solutions can more quickly be implemented in Python than in C. For people who want to broaden the scope of Python, there is the option of using some of the models that the PyPy project has implemented, or roll their own. Constraints satisfaction, lazy evaluation, cooperative massive multitasking, security oriented environments, transparent distributed computing and persistence are examples of things the project have implemented. There are some very neat APIs so that you can easily add your own behaviour to the Python interpreter. For those who want to do Computer Science, PyPy offers a wonderful research platform. For instance, you can experiment with alternate or even multiple implementations of builtin types. You can build frontends for your favourite programming language and backends for your favourite platform. Since Javascript is a backend that we already handle fairly well, you can write your FORTRAN parser and have a FORTRAN to JS compiler. The neat thing is that once you build the parser, you should automatically have your code working on all the different backends. (This is a goal and not quite reality at this point in time. Bugs and shortcomings will still be in the way.) There is a tradeoff in computer language design between execution speed flexibility and ease of use. I personally think that PyPy is about to break out of the tradeoff and bring it to another level. I know that I am biased, having been involved with the project from the start, but I think that it is the most interesting work in CS in many years. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Python component model
In article <[EMAIL PROTECTED]>, Peter Wang <[EMAIL PROTECTED]> wrote: ... >functions at ever higher levels of abstraction, or to have a >proliferation of nebulously-defined "manager" objects.) IMHO once you >cross this chasm and are able to model your problem domain with live >objects that go off and automatically respond to the runtime >environment and Do the Right Thing, it's very hard to go back to a dead >object mindset. I can understand, however, that until one makes this >leap, it might seem like an academic and useless distinction. I'm not disagreeing with the blessings of components reacting to events and going off Doing the Right Thing. However, there is a huge with components going off Doing the Wrong Thing. It becomes exceedingly hard to debug for several reasons. The first one is that it is difficult to trace the callbacks generated, since the point where they were registered is no longer trackable when your problem occurs. The second and most serious problem is that erroneous behaviour in two components can interact in extremely mysterious ways that are really difficult to debug. In part these problems can be reduced by much rigorous testing of each component than is the norm today, but for the really tough problems we need tools that have not been invented yet, that track the history of each callback. Since these tools have to understand the details of the calling conventions and registration mechanism for events, they have to be custom built for each component framework and should therefore be part of the framework distribution. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't use __slots__ (was Re: performance of dictionary lookup vs. object attributes)
In article <[EMAIL PROTECTED]>, Patrick Maupin <[EMAIL PROTECTED]> wrote: >I didn't actually sense any dander on your part, so it was probably a >bit unfortunate that I chose to respond to that particular message. I >do (rightly or wrongly) sense some dander on Aahz's part, and this was >the second or third thread where I saw him respond in a similar terse >fashion, but I wasn't really motivated to respond until I saw your >response to his response to, well, you know... > >And I know that the BDFL thinks it's a mistake, and he's probably >right. In my previous post, I attempted to rationalize why this is >true. For a start, Guido is probably continually hounded by people >asking stupid __slots__ questions. > >Nonetheless, this is one of the few topics on CLP where innocent, >rational questions are more often than not answered with "because I >said so", so I was trying to inject a bit of nuance into the >discussion. (For most similar technical questions, someone will post a >pointer to a post or document which explains in clear technical detail >WHY things are bad, but for this issue there seems to be no comparable >source -- just that rant of the BDFL, which certainly carries a lot of >weight in terms of best practices, but which I find woefully inadequate >in terms of explanations which are dumbed-down enough for me to >follow.) > >Also, as I noted, I _do_ use them on occasion, so if there really _are_ >potential pitfalls there, I would like to understand exactly what they >are, so my ears perk up whenever I notice a __slots__ discussion, but >so far I have been repeatedly disappointed, in that I always see >someone saying "don't do that" but I have never seen a cogent technical >argument about how my scripts which __slots__ are going to suddenly, >irretrievably break one day. The proper use of__slots__is to save space in objects. Instead of having a dynamic dict that allows adding attributes to objects at anytime, there is a static structure which does not allow additions after creation. This saves the overheadof one dict for every object that uses slots. While this is sometimes a useful optimisation, it would be completely unnecessary if the Python interpreter was dynamic enough so that it would only require the dict when there actually were additions to the object. Unfortunately there is a side effect to slots. They change the behaviour of the objects that have slots in a way that can be abused by control freaks and static typing weenies. This is bad, because the contol freaks should be abusing the metaclasses and the static typing weenies should be abusing decorators, since in Python,there should be only one obvious way of doing something. Making CPython smart enough to handle saving space without __slots__ is a a major undertaking, which is probably why it is not on the list of changes for P3k (yet). Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Twisted book opinions?
In article <[EMAIL PROTECTED]>, Andrew Gwozdziewycz <[EMAIL PROTECTED]> wrote: >> It's really more of an example based tutorial book than cookbook. >> What it does do really well is 'networking programming essentials'. I >> found it quite a good book and managed to write a distributed ssh cron >> tool in an evening after reading the sections on SSH. > >I would second that. The examples are very good, and it breaks down >the code and explains the new concepts. > >> What I'd really like now is a 'Web Application Development with >> Twisted/Nevow' book that takes off where this 'network protocol' >> oriented book leaves off. > >I thought the O'Reilly book was pretty decent at describing how to >setup a web application. It's not entirely complete, but I was able to >piece together an application with a somewhat complex web application >on top of it. Twisted made it quite easy. The book does Twisted basics very well. The examples are many and they are just the right size for grasping how to do things. My only gripe is that the way it produces HTML code in the web examples is very primitive. You should be using Stan (a very Pythonic DOM) instead of the explicit strings that are used throughout the book. Fortunately there is an on-line tutorial for Stan, which is very good. http://www.kieranholland.com/code/documentation/nevow-stan/ Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: python coding contest
In article <[EMAIL PROTECTED]>, Simon Hengel <[EMAIL PROTECTED]> wrote: >Hello, > >> After all, I'd really love to set up another contest with >> different measures and criteria. > >for future events i will take a close look at other possibilities for >doing a ranking. At the moment the 22c3 and the contest is eating up all >my time. Pleas appreciate that i may not keep up with all mails. Sorry >for that. For whatever it is worth, I enjoyed myself thoroughly thinking about the problem, discussing it and listening to others discuss it. It was FUN! It is built into all requirements for shortest or fastest that the winning solution will be using obscure features and combinations in order to make the absolutely optimal solution. This doesn't really matter unless your goals are to demonstrate the elegance of the programming language. If you want to provide an alternative to solving crossword puzzles or mega-hard Sudoku's for the Christmas holiday, I'd say this is spot on. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Re: where to download md5.py?
In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >"Bell, Kevin" wrote: > >> I've been looking around, but haven't found a place to download the >> md5.py module. I need it to run the dupinator.py > >md5 is a standard Python module (written in C). it's been in Python since >the early ages, so if you don't have it, your install is most likely >broken (per- >haps intentionally, based on this: http://eprint.iacr.org/2004/199 ) A pure python implementation of md5 is included in the pypy project. It is naturally a lot slower than the C module, but it does the job. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Europython 2005 - last call
Europython 2005 will start on Monday 27 June! If you haven't preregistered for Europython 2005, you still have a few hours to do so. You can register and pay by credit card until 21 June 18.00 CEST. Payment by SWIFT/IBAN is closed, since we would not receive your payment before the conference starts. On-site registration is also possible, though at a somewhat higher cost. Pyment on-site is in cash, SEK or Euro. Please bring even money since we can't have a big pile of change at the conference. All details are found at http://www.europython.org. -- -- http://mail.python.org/mailman/listinfo/python-list
Europython update
The Europython schedule was publised on the Europython website (http://www.europython.org) today. With five parallel sessions for half of the conference and four for the rest, we think we have the largest selection of Python and Zope talks ever. "Actually, we are more proud of the quality of the talk toipcs than of the quantity", says Paul Everitt, chairman of the Zope and Zope related track. "I'm very excited about the Tutorials track", says Harald Armin Massa. "We have the perfect setup for introducing new people to the world of Python. I can't wait to get started." "We hope that many more people will register, now that the schedule is set", comments Jacob Hallén, the conference head organiser. "We have had an unusual procedure, where the early registrants have told us their interests in the different talks. This has provided us with excellent data for scheduling. If people stick to what they have told us, there will be no overcrowding of rooms and fewer clashes beween interesting talks than usual. However, it has made the final scheduling fairly late, so people who have waited need to register in the next few days." "We still have a few double rooms at the conference accomodations" adds Laura Creighton. "The 4-bed rooms are all sold out." Apart from the Zope and Tutorials/Neopythe track, there are tracks for Education, Science, Refereed Papers, Business, Python Language, Python Frameworks, Social Skills/General Topics and a special Misfits track for stuff that would otherwise fall between the cracks. There is also OpenSpace, Lightning talks and Zope lightning talks. On top of this, we have 2 exciting Keynotes, featuring Guido van Rossum and Steve Pemberton, a pub, a conference dinner and lots of other excitement. Last day for preregistration is 20 June, if you are paying by credit card and 17 June if you are paying by SWIFT/IBAN. After that, your only option is on-site registration. The last day for ordering a conference T-shirt is 15 June. -- -- http://mail.python.org/mailman/listinfo/python-list
Re: Optimise Europython competition
In article <[EMAIL PROTECTED]>, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: >Jacob Hallen wrote: >> 2. A track should be continuous. Each track that is continuous gives you >>10 points. > >What exactly do you mean by "continuous track"? Continuous means that from the time of the first talk in the track until all talks in the track have been given, there will be a talk from the track in each time slot (in exceptional cases there can be an empty time slot inserted to make things fit, but usually that is not needed.) The main reason for this rule is that some people only come for a few talks in a specific track, and they don't want to have to stay 3 days because we scheduled some on Monday morning and the rest on Wednesday morning. Last year we even had 2 people driving down from Norway, paying the 270 Euro on-site fee, just to listen to a single talk. They then had a chat with the speaker and went home, quite happy with their conference. Jacob Hallén -- -- http://mail.python.org/mailman/listinfo/python-list
Optimise Europython competition
A classic dilemma for conferences is that if you have many tracks, you may find that all of a sudden, a room is swamped, and there is a queue of people wanting to get in. Another problem is that you risk scheduling talks against each other that have a very large set of interested people in common. At Europython we are this year going to try a new way of scheduling, in order to reduce these problems. Before the schedule is made, we will give all attendees the opportunity to register what talks they are most interested in. We then want to make a schedule that is optimised based on these data. Since I am no expert in optimising algorithms of this type, and since the time I have available for these things is limited, I'm turning to the readers of c.l.p and python-logic for help. I'm offering the following bounty for a working solution (in Python): - Free attendance at this years Europython, as a guest of honour - A Europython T-shirt in a limited special edition - Fame and gratitude from conference attendees who get better scheduling The winner of the bounty is the person who scores most points, according to the criteria below. If we get more than one solution that does good optimisation, we will award more than one bounty. Here are the parameters: 1. There are 10 tracks with between 1 and 30 talks in each track. You may not schedule two talks in the same track against each other, unless there is more talks than available calendar time. 2. A track should be continuous. Each track that is continuous gives you 10 points. 3. We expect about 300 attendees. About half of them are expected to register their interests. Interests may range from a single talk to more than half of all the talks. You get one point for each talk an attendee can attend out of the ones the attendee has registered interest in. 4. Talks are of varying lengths. Lengths can be 30, 45, 60 and 90 minutes. The large majority of talks are 30 minutes. Only a very few are 45 minutes. 5. Rooms come in different sizes Room A has 180 seats Room B has 140 seats Room C has 140 seats Room D has 70 seats Room E has 70 seats Room A-D should be scheduled throughout the conference while room E is extra expansion space, only to be used when absolutely necessary. For every person scheduled above (Room capacity * (Number of responding attendees / Total number of attendees)) you get one point taken off your score. 6. There are a total of 10 90-minute time blocks. Day 1: 09:00 Day 1: 11:00 Day 1: 14:00 Day 1: 16:00 Day 2: 09:00 Day 2: 11:00 Day 2: 14:00 Day 2: 16:00 Day 3: 09:00 Day 3: 11:00 A track should not change room in the middle of a time block. Doing so reduces your score by 50 points. 7. Input data You get your input data in the form of a list of tuples; one tuple per talk. Each tuple looks like this: (, , , [list of interested attendees]) Talk length is an integer, all other items are strings. 8. Output data You should supply your output data in the form of a list of tuples; one tuple per talk. Each tuple should look like this: (, , , ) Talk id should be the same as in the input. Room should be a one letter string with a value in the range A-E. Day should be a one letter string in the range 1-3. Starting time should be a string on the form HH:MM, in the 24 hour clock. Solutions should be sent by email to europython@python.org no later than 1 June 2005. Currently we haven't started gathering real data, but there should be some available for real world testing before 1 June. -- -- http://mail.python.org/mailman/listinfo/python-list
Europython update
This is a news update about the Europython 2005 conference, to be held in Göteborg, Sweden 27-29 June - We have received a very nice array of talks this year, and we expect to be the biggest Python conference ever in terms of subjects covered. Many thanks to all the speakers who are putting their efforts into this. - A list of talks is now available,either through the "Track Overview" menu item on the Europython website, or directly at http://www.python-in-business.org/ep2005/atracks.chtml - Around the end of May we will be soliciting input from all attendees on what talks they aremost interested in. This information will be used in scheduling, in order to reduce the amounts of collisions between popular talks and in order to reduce the risk of overcrowding a small room with a talk that turns out to be very popular. - Early bird registrations end 15 May. Registration for the low cost accomodation close to the conference venue ends on the same day. We may have further accomodation available at a later date, but we can't make any promises. - Please help us become the biggest Python/Zope conference. Talk to your friends about Europython and write about the conference in your blog. The more people who show up, the more we can spend on getting the best and most interesting talks. - This year we have a special focus on Python newbies in the Tutorials track. If you have staff or customers who need a well rounded introduction to Python, send them to Europython 2005. For all conference details, go to: http://www.europython.org See you in Göteborg. EuroPython Team. About EuroPython: Europython is an annual conference for the Python and Zope communities. It circulates between different sites in Europe. Having started in Charleroi, Belgium, it is now in Göteborg, Sweden and will move to CERN in Swizerland next year. Europython is a community conference run by volunteers. -- -- http://mail.python.org/mailman/listinfo/python-list
Europython update
This is a news update about the Europython 2005 conference, to be held in Göteborg, Sweden 27-29 June - Due to some technical prolems with the registration website we have decided to extend the registration of talks until 8 May. We already have an impressive array of talks, but we do have room for some more. We are especially interested in talks focusing on the Python language and talks on Python usage in Science. - To encourage companies to bring their whole staff and their customers to Europython, we have created a corporate discount. If you bring 5 people or more from a single organisation, you get a 20% discount on the regular and early-bird regular fee. - A list of all the accepted talks will be published 11 May 2005 on the Europython website. - Early bird registrations end 15 May. Registration for the low cost accomodation close to the conference venue ends on the same day. For all conference details, go to: http://www.europython.org See you in Göteborg. EuroPython Team About EuroPython: Europython is an annual conference for the Python and Zope communities. It circulates between different sites in Europe. Having started in Charleroi, Belgium, it is now in Göteborg, Sweden and will move to CERN in Swizerland next year. Europython is a community conference run by volunteers. -- -- http://mail.python.org/mailman/listinfo/python-list
Europython 2005 registration open
EuroPython is held -for the second time- in Göteborg, Sweden, during the week of June 27-29, 2005. Registration is open and now is your chance to submit a proposal (or more). Several topics are handled in parallel tracks at EuroPython2005, these include: Business, Education, Lightning talks, Python Frameworks, Python Language, Refereed papers, Science, Social skills/General topics, Tutorials/Neopythes, Zope and Zope Related, Zope Lightning talks. If you would like to tell the community something about your work, interest or experience, then then submit button is your way to go. The Refereed Track is intended for prestigious peer-reviewed talks for presenting technical and scientific papers. To our knowledge, EuroPython is the only Python conference, with peer-reviewed talks. Everybody can submit a paper for the Refereed Track, as long as it follows the Refereed paper instructions. For detailed information concerning this subject, please have a look at the Tracks & Talks webpage of EuroPython. To give you yet another opportunity to submit a refereed paper, we have extended the deadline to coincide with the deadline for regular talks. Lat day for submission is 1 May 2005! If you don't want to participate as a speaker, you might be interested in hearing the talks. Registration for EuroPython2005 is now open. Several registration alternatives are possible. Pre-Registration will be available until 17th of June, but Early Bird registration will end on May the 15th. Everybody is welcome: from novice to advanced. Our keynote speakers will be Guido van Rossum and Steve Pemberton. You may not have heard of Steve, since his focus is in an area that is not directly connected to Python. However, we expect him to give you an interesting perspective on what is going on in the industry. Find out more at http://homepages.cwi.nl/~steven/. If you don't know who Guido van Rossum is, you really need to come to Europython to find out. Feel free to spread the word about EuroPython2005 to your friends, family, colleagues, ... For all conference details, go to: http://www.europython.org See you at Göteborg. EuroPython Team. About EuroPython: Europython is an annual conference for the Python and Zope communities. It circulates between different sites in Europe. Having started in Charleroi, Belgium, it is now in Göteborg, Sweden and will move to CERN in Swizerland next year. Europython is a community conference run by volunteers. -- -- http://mail.python.org/mailman/listinfo/python-list
Europython 2005 is now accepting talk submissions
Europython 2005 is now accepting talk submissions! Find out more at http://www.europython.org Just as last year, we have a Refereed Paper Track. Last day for proposing a refereed paper is 22 April 2005. For regular talks, we have the following tracks: Business Education Python Frameworks Python Language Science Social skills and General Topics Zope/Plone We also have a special track for "Misfits" this year. It is for any topic that is Python related but doesn't fit in any of the above categories. Last day for submitting talks to the regular tracks is 1 May 2005. On top of this, we will have two tracks of Lightning Talks; one for Zope/plone and one for other topics. You can register talks for these all the time until the Lightning Talk sessions end, or the schedule is filled, whichever comes first. Europython 2005 will be held 27-29 June at the Chalmers University of Techchnology, Göteborg, Sweden. Registration will open in mid-April. We hope this will become the best Europython Conference ever! With your help it can. We are still seeking volunteers to help us with a number of things. We have a recent vacancy as track chair for Python Frameworks, and it is not too late to revive the Applications Track. We also need people to help out in the reception during the conference. Send an email to [EMAIL PROTECTED] Jacob Hallén Head organiser -- -- http://mail.python.org/mailman/listinfo/python-list
